Create a new PodSecurityPolicy named prevent-psp-policy, which prevents the creation of privileged Pods. Create a new ClusterRole named restrict-access-role, which uses the newly created…

This question tests your ability to implement Kubernetes Pod Security Policy (PSP) RBAC enforcement by chaining together a PodSecurityPolicy, ClusterRole, ServiceAccount, and ClusterRoleBinding to prevent privileged Pod creation in a namespace.

Submitted by klara.se· May 4, 2026Cluster Hardening

Question

Create a new PodSecurityPolicy named prevent-psp-policy, which prevents the creation of privileged Pods.
Create a new ClusterRole named restrict-access-role, which uses the newly created PodSecurityPolicy prevent-psp-policy.
Create a new ServiceAccount named psp-restrict-sa in the existing namespace staging.
Finally, create a new ClusterRoleBinding named restrict-access-bind, which binds the newly created ClusterRole restrict-access-role to the newly created ServiceAccount psp-restrict-sa.

Explanation

Approach. First, create a PodSecurityPolicy named 'prevent-psp-policy' with 'privileged: false' under spec, which blocks any Pod requesting privileged mode. Next, create a ClusterRole named 'restrict-access-role' that grants the 'use' verb on the 'podsecuritypolicies' resource (apiGroup: policy) referencing 'prevent-psp-policy' by resourceName - this is the required RBAC bridge that allows subjects to 'use' the PSP. Then create a ServiceAccount named 'psp-restrict-sa' in the 'staging' namespace, which will act as the identity that must comply with the policy. Finally, create a ClusterRoleBinding named 'restrict-access-bind' that binds the ClusterRole to the ServiceAccount (subject kind: ServiceAccount, name: psp-restrict-sa, namespace: staging) - once bound, any Pod scheduled under that ServiceAccount is validated against 'prevent-psp-policy' and rejected if it requests privileged access.

Concept tested. Kubernetes PodSecurityPolicy (PSP) enforcement via RBAC: understanding that a PSP alone does not enforce itself - it must be activated through a ClusterRole with the 'use' verb and bound to a ServiceAccount via a ClusterRoleBinding. This tests the full PSP admission control chain: PSP → ClusterRole (use verb) → ClusterRoleBinding → ServiceAccount.

Reference. https://kubernetes.io/docs/concepts/policy/pod-security-policy/ - Note: PSP was deprecated in Kubernetes v1.21 and removed in v1.25; replaced by Pod Security Admission (PSA). Exam context (CKA/CKAD on older cluster versions) may still test PSP.

Topics

#PodSecurityPolicy#RBAC#ServiceAccount#Privileged Containers

Community Discussion

No community discussion yet for this question.

Full CKS Practice