To allow for the deployment of privileged pods in a Tanzu Kubernetes cluster, you can create a RoleBinding to the default privileged pod security policy.

Deploying the Guestbook application is a common way for developers to explore Kubernetes. If you deploy all the Guestbook YAML files to a Tanzu Kubernetes cluster provisioned by the Tanzu Kubernetes Grid Service, the application pod is not created successfully. The following error message appears when you run the kubectl describe pod command:

“Error: container has runAsNonRoot and image will run as root”

The Guestbook application is using both deployment and replicaset resources to deploy privileged containers in the default namespace. Because the PodSecurityPolicy Controller is enabled for Tanzu Kubernetes clusters, when any cluster user attempts to create the Guestbook application pod, the service accounts for these controllers are checked against PodSecurityPolicy. If an appropriate PSP is not bound to these service accounts, the application is not deployed.

By default, Tanzu Kubernetes administrators can create privileged pods directly in any namespace using their user account. However, the Guestbook application deploys privileged containers using service accounts. A cluster administrator can create Deployments, StatefulSets, and DaemonSet in the kube-system namespace. However, the Guestbook application deploys these resources in the default namespace. In addition, non-administrative users cannot create privileged or unprivileged pods at all without the proper PSP and bindings.

One solution is to create bindings to the default privileged PSP to allow the Guestbook application to be deployed. The privileged PodSecurityPolicy permits run-as-root pods and privileged containers for bound accounts. You can create a ClusterRoleBinding that applies the vmware-system-privileged cluster-wide, but doing so might violate the principle of least privilege by granting more permission than is needed. A better approach is to create a RoleBinding that permits the system service accounts to use the privileged PodSecurityPolicy in the default namespace.

Note: The instructions describe how to create the RoleBinding using YAML. For the equivalent kubectl command, see Example 1: RoleBinding to Run a Privileged Set of Workloads.

Procedure

  1. To define the RoleBinding resource, create the following YAML file.
    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
    
  2. Use kubectl to apply the YAML file and create the resource.
    kubectl apply -f ROLEBINDING-YAML-FILE-NAME

What to do next

After the RoleBinding is created, you can deploy the Guestbook application to the default namespace by following the steps in the Guestbook application tutorial.