Tanzu Kubernetes Grid Service provisions Tanzu Kubernetes clusters with the PodSecurityPolicy Admission Controller enabled. This means that pod security policy is required to deploy workloads. Cluster administrators can deploy pods from their user account to any namespace, and from service accounts to the kube-system namespace. For all other use cases, you must explicitly bind to pod security policy. Clusters include default pod security policies that you can bind to, or create your own.

About Kubernetes Pod Security Policies

Kubernetes pod security policies (PSPs) are cluster-level resources that control the security of pods. Using PSPs gives you control over the types of pods that can be deployed and the types of accounts that can deploy them.

A PodSecurityPolicy resource defines a set of conditions that a pod must satisfy to be deployable. If the conditions are not met, the pod cannot be deployed. A single PodSecurityPolicy must validate a pod in its entirety. A pod cannot have some of its rules in one policy and some in another.

There are various ways to implement the use of pod security policies in Kubernetes. The typical approach is by using role-based access control (RBAC) objects. ClusterRole and ClusterRoleBinding apply cluster-wide; Role and RoleBinding apply to a specific namespace. If a RoleBinding is used, it only lets pods run in the same namespace as the binding.

There are two ways to create Kubernetes pods: directly or indirectly. You create a pod directly by deploying a pod spec with your user account. You create a pod indirectly by defining some higher-level resource, such as a Deployment or DaemonSet. In this case, a service account creates the underlying pod.

To use PSPs effectively, you must account for both pod creation workflows. If a user creates a pod directly, the PSP bound to the user account controls the operation. If a user creates a pod by way of a service account, the PSP must be bound to the service account used to create the pod. If no service account is specified in the pod spec, the default service account for the namespace is used.

For more information, see Pod Security Policies, RBAC, and Service Accounts in the Kubernetes documentation.

Default PodSecurityPolicy for Tanzu Kubernetes Clusters

The table lists and describes the privileged and restricted default pod security policies for Tanzu Kubernetes clusters, and the default ClusterRole associated with each policy.
Table 1. Default PodSecurityPolicy with Associated ClusterRole
Default PSP Permission Description Associated Default ClusterRole
vmware-system-privileged Run as any Permissive PSP. Equivalent to running a cluster without the PSP Admission Controller enabled. psp:vmware-system-privileged can use this PSP
vmware-system-restricted Must run as non-root Restrictive PSP. Does not permit privileged access to pod containers, blocks possible escalations to root, and requires use of several security mechanisms. psp:vmware-system-restricted can use this PSP

No Default Bindings for Tanzu Kubernetes Clusters

The Tanzu Kubernetes Grid Service does not provide default RoleBinding and ClusterRoleBinding for Tanzu Kubernetes clusters.

A vCenter Single Sign-On user who is granted the Edit permission on a Supervisor Namespace is assigned to the cluster-admin role for any Tanzu Kubernetes cluster deployed in that namespace. An authenticated cluster administrator can implicitly use the vmware-system-privileged PSP. Although not technically a ClusterRoleBinding, it has the same effect.

The cluster administrator must define any bindings to allow or restrict the types of pods users can deploy to a cluster. If a RoleBinding is used, the binding only allows pods to be run in the same namespace as the binding. This can be paired with system groups to grant access to all pods run in the namespace. Non-admin users who authenticate to the cluster are assigned to the authenticated role and can be bound to default PSP as such. See Grant Developer Access to Tanzu Kubernetes Clusters.

Effect of Default PodSecurityPolicy on Tanzu Kubernetes Clusters

The following behavior is enforced for any Tanzu Kubernetes cluster: