Create a PSP that will prevent the creation of privileged pods in the namespace. Create a new PodSecurityPolicy named prevent-privileged-policy which prevents the creation of privileged pods. Create…

This question tests your ability to implement Kubernetes PodSecurityPolicy (PSP) combined with RBAC to enforce pod-level security constraints - specifically preventing privileged containers from running in a cluster.

Submitted by weili_xi· May 4, 2026Cluster Hardening

Question

Create a PSP that will prevent the creation of privileged pods in the namespace.
Create a new PodSecurityPolicy named prevent-privileged-policy which prevents the creation of privileged pods.
Create a new ServiceAccount named psp-sa in the namespace default.
Create a new ClusterRole named prevent-role, which uses the newly created Pod Security Policy prevent-privileged-policy.
Create a new ClusterRoleBinding named prevent-role-binding, which binds the created ClusterRole prevent-role to the created SA psp-sa.
Also, Check the Configuration is working or not by trying to Create a Privileged pod, it should get failed.

Explanation

Approach. The correct approach involves four tightly coupled Kubernetes objects. First, create a PodSecurityPolicy with privileged: false in its spec - this is the actual enforcement rule. Second, create a ClusterRole that grants use verb on the podsecuritypolicies resource (API group: policy), scoped to the specific PSP by name. Third, bind that ClusterRole to the target ServiceAccount via a ClusterRoleBinding. PSP admission control only enforces a policy when the pod's associated ServiceAccount (or the user creating the pod) has been explicitly granted use permission on that policy - without the RBAC binding, the PSP is defined but never enforced. Finally, verify by creating a pod with securityContext.privileged: true under the psp-sa service account; it must be rejected by the admission controller, confirming enforcement is active.

Concept tested. Kubernetes PodSecurityPolicy (PSP) enforcement via RBAC - specifically the mandatory three-layer chain: PSP definition (spec.privileged=false) → ClusterRole with use verb on the PSP → ClusterRoleBinding linking the ClusterRole to a ServiceAccount. A common mistake is defining the PSP without wiring the RBAC, which results in the policy existing but never being evaluated. Note: PSP was deprecated in Kubernetes v1.21 and removed in v1.25; modern clusters use PodSecurity Admission (PSA) with namespace labels instead.

Reference. https://kubernetes.io/docs/concepts/policy/pod-security-policy/ (archived) | CKS exam domain: Minimize Microservice Vulnerabilities

Topics

#Pod Security Policy (PSP)#RBAC#ServiceAccount#Privileged Containers

Community Discussion

No community discussion yet for this question.

Full CKS Practice