TKG Service clusters using TKR 1.24 and eariler include default pod security policy that you can bind to for privileged and restricted workload deployment.

Applying Default Pod Security Policy Using Role and ClusterRole Bindings

vSphere IaaS control plane provides default pod security policy that you can apply to TKG clusters on Supervisor running TKR 1.24 and eariler. You can do this by creating RoleBinding and ClusterRoleBinding objects that reference default pod security policy.
Note: Refer to the Kubernetes documentation to author your own Pod Security Policy.

A RoleBinding grants permissions within a specific namespace. A ClusterRoleBinding grants permissions cluster-wide. The decision to use a RoleBindings or ClusterRoleBinding depends on your use case. For example, if you use a ClusterRoleBinding and configure subjects to use system:serviceaccounts:<namespace>, you can bind to a PSP before the namespace is created. For more information, see RoleBinding and ClusterRoleBinding in the Kubernetes documentation.

The following sections provide YAML and CLI commands for creating RoleBinding and ClusterRoleBinding objects that authorize the use of default pod security policy.

Example 1: ClusterRoleBinding to Run a Privileged Set of Workloads

The following kubectl command creates a ClusterRoleBinding that grants access to authenticated users run a privileged set of workloads using the default PSP vmware-system-privileged.
Warning: Applying Example 1, declaratively or imperatively, allows the deployment of privileged workloads cluster-wide. In effect Example 1 disables native security controls and should be used with caution and full awareness of the implications. For tighter security, consider Examples 2, 3, and 4. 
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: psp:privileged
rules:
- apiGroups: ['policy']
  resources: ['podsecuritypolicies']
  verbs:     ['use']
  resourceNames:
  - vmware-system-privileged
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: all:psp:privileged
roleRef:
  kind: ClusterRole
  name: psp:privileged
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: Group
  name: system:serviceaccounts
  apiGroup: rbac.authorization.k8s.io
As an alternative to applying YAML, you can run the following kubectl command. 
kubectl create clusterrolebinding default-tkg-admin-privileged-binding --clusterrole=psp:vmware-system-privileged --group=system:authenticated

Example 2: RoleBinding to Run a Privileged Set of Workloads

The following kubectl command creates a RoleBinding that grants access to all service accounts within the default namespace to run a privileged set of workloads using the default PSP vmware-system-privileged. 
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: rolebinding-default-privileged-sa-ns_default
  namespace: default
roleRef:
  kind: ClusterRole
  name: psp:vmware-system-privileged
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: Group
  apiGroup: rbac.authorization.k8s.io
  name: system:serviceaccounts
As an alternative to applying YAML, you can run the following kubectl command. 
kubectl create rolebinding rolebinding-default-privileged-sa-ns_default --namespace=default --clusterrole=psp:vmware-system-privileged --group=system:serviceaccounts

Example 3: ClusterRoleBinding to Run a Restricted Set of Workloads

The following YAML creates a ClusterRoleBinding that grants authenticated users cluster-wide access to run a restricted set of workloads using the default PSP vmware-system-restricted.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: psp:authenticated
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:authenticated
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: psp:vmware-system-restricted

As an alternative to applying YAML, you can run the following kubectl command.

kubectl create clusterrolebinding psp:authenticated --clusterrole=psp:vmware-system-restricted --group=system:authenticated

Example 4: RoleBinding to Run a Restricted Set of Workloads

The following YAML creates a RoleBinding that grants access to all service accounts within a specific namespace to run a restricted set of workloads using the default PSP vmware-system-restricted.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: psp:serviceaccounts
  namespace: some-namespace
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:serviceaccounts
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: psp:vmware-system-restricted
As an alternative to applying YAML, you can run the following kubectl command.
Note: Change "some-namespace" to the target namespace. 
kubectl create rolebinding psp:serviceaccounts --clusterrole=psp:vmware-system-restricted --group=system:serviceaccounts -n some-namespace

Example Role for Pod Security Policy

If you define your own pod security policy (PSP) to deploy workloads, refer to this example to create a Role or ClusterRole that references the custom PSP.

The example demonstrates a Role bound to a PodSecurityPolicy. In the role definition, the example-role is granted the use verb to a custom PSP resource that you define. Alternatively, use one of the default PSPs. Then, create a binding.

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: Role
metadata:
  name: example-role
  namespace: tkgs-cluster-ns
rules:
- apiGroups:
  - ""
  resources:
  - configmaps
  verbs:
  - create
  - get
  - list
  - watch
  - update
- apiGroups:
  - ""
  resources:
  - events
  verbs:
  - create
  - update
  - patch
- apiGroups: 
  - extensions
  resourceNames:
  - CUSTOM-OR-DEFAULT-PSP
  resources:
  - podsecuritypolicies
  verbs:
  - use