Context: A PodSecurityPolicy shall prevent the creation of privileged Pods in a specific namespace. Task: 1. Create a new PodSecurityPolicy named deny-policy, which prevents the creation of privileged Pods. 2. Create a new ClusterRole name deny-access-role, which uses the newly created PodSecurityPolicy deny-policy. 3. Create a new ServiceAccount named psp-denial-sa in the existing namespace development Finally, create a new ClusterRoleBindind named restrict-access-bind, which binds the newly created ClusterRole deny-access-role to the newly created ServiceAccount psp-denial-sa

Linux_Foundation

CKS · Question #27

Context: A PodSecurityPolicy shall prevent the creation of privileged Pods in a specific namespace. Task: 1. Create a new PodSecurityPolicy named deny-policy, which prevents the creation of…

This question tests the ability to enforce Pod-level security constraints in Kubernetes using PodSecurityPolicy (PSP) combined with RBAC - specifically creating a PSP that blocks privileged containers and wiring it to a ServiceAccount via ClusterRole and ClusterRoleBinding.

Submitted by yousef_jo· May 5, 2026Cluster Hardening

Question

Context:
A PodSecurityPolicy shall prevent the creation of privileged Pods in a specific namespace.
Task:
Create a new PodSecurityPolicy named deny-policy, which prevents the creation of privileged Pods.
Create a new ClusterRole name deny-access-role, which uses the newly created PodSecurityPolicy deny-policy.
Create a new ServiceAccount named psp-denial-sa in the existing namespace development

Finally, create a new ClusterRoleBindind named restrict-access-bind, which binds the newly created ClusterRole deny-access-role to the newly created ServiceAccount psp-denial-sa

Explanation

Approach. PSPs are enforced only when a ServiceAccount (or user) has RBAC permission to 'use' the policy - creating the PSP alone does nothing. The correct sequence is: (1) Create the PodSecurityPolicy 'deny-policy' with spec.privileged: false (plus required fields like seLinux, runAsUser, fsGroup, supplementalGroups set to RunAsAny); (2) Create a ClusterRole 'deny-access-role' with a rule granting apiGroups: ['policy'], resources: ['podsecuritypolicies'], verbs: ['use'], resourceNames: ['deny-policy']; (3) Create ServiceAccount 'psp-denial-sa' in namespace 'development' with kubectl create serviceaccount psp-denial-sa -n development; (4) Create ClusterRoleBinding 'restrict-access-bind' binding ClusterRole 'deny-access-role' to subject kind: ServiceAccount, name: psp-denial-sa, namespace: development. Any Pod scheduled using that ServiceAccount will be validated against deny-policy and rejected if it requests privileged mode.

Concept tested. Kubernetes PodSecurityPolicy enforcement via RBAC - understanding that PSPs require a 'use' permission granted through a ClusterRole/ClusterRoleBinding to a ServiceAccount before the admission controller will apply them, and knowing the mandatory PSP spec fields (privileged, seLinux, runAsUser, fsGroup, supplementalGroups) required for a valid policy object.

Reference. https://kubernetes.io/docs/concepts/policy/pod-security-policy/ (deprecated in v1.21, removed in v1.25; replaced by Pod Security Admission - verify exam K8s version)

Topics

#PodSecurityPolicy (PSP)#RBAC#Privileged Containers#Admission Control

Community Discussion

No community discussion yet for this question.

Full CKS Practice