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 a PodSecurityPolicy object. 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
| 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 vSphere 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
- 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 namespace, see Tanzu Kubernetes Guestbook Tutorial.
- 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. See Tanzu Kubernetes Guestbook Tutorial.
