TKG on Supervisor supports pod security using the Pod Security Policy admission controller, which is enabled by default for TKG clusters using TKR v1.24 and earlier.
Prerequisite: TKR 1.24 and Earlier
The content is this topic applies to TKG clusters on Supervisor that are provisioned with TKR v1.24 and earlier. By default these Tanzu Kubernetes releases enable the Pod Security Policy admission controller.
The successor to the Pod Security Policy admission controller is the Pod Security admission controller. TKG clusters on Supervisor provisioned with TKR v1.25 and later enable the Pod Security admission controller. See Configure PSA for TKR 1.25 and Later.
Pod Security Policy Admission Controller
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. For more information, see Pod Security Policies, RBAC in the Kubernetes documentation.
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. For more information, see RBAC in the Kubernetes documentation.
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. For more information, see Service Accounts in the Kubernetes documentation.
To use PSPs effectively, you must account for both pod creation workflows: direct and indirect. 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.
Default PodSecurityPolicy for TKG Clusters
| 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 |
Role and ClusterRole Bindings for TKG Clusters
TKG on Supervisor does not provide default RoleBinding and ClusterRoleBinding for TKG clusters. Examples that you can use are provided in this documentation. See Apply Default Pod Security Policy to TKG Service Clusters.
A vCenter Single Sign-On user who is granted the Edit permission on a vSphere Namespace is assigned to the cluster-admin role for any TKG 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.
- A cluster administrator can create privileged pods directly in any namespace by using his or her user account.
- A cluster administrator can create Deployments, StatefulSets, and DaemonSet (each of which creates privileged pods) in the kube-system namespace. If you want to use a different Kubernetes namespace, create a RoleBinding for it, or a ClusterRoleBinding.
- A cluster administrator can create his or her own PSPs (in addition to the two default PSPs) and bind these PSPs to any users. If you define your own PSP, see Policy Order in the Kubernetes documentation.
- No authenticated users can create privileged or unprivileged pods until the cluster administrator binds PSPs to the authenticated users.
For binding examples, see Apply Default Pod Security Policy to TKG Service Clusters.
