Make a Deployment Pass the Restricted Pod Security Standard

Original Prepium guide · Written for Kubernetes v1.35 and checked against the official documentation on 6 October 2026. Use a disposable practice cluster.

Read a Pod Security rejection and satisfy the restricted profile

The Pod Security Standards define three profiles: privileged (no restrictions), baseline (blocks known privilege escalations such as privileged containers, host namespaces and hostPath) and restricted (baseline plus current hardening practice). The built-in Pod Security Admission controller applies them per namespace, driven by labels. In the exam the namespace is usually already labelled; your job is to read why Pods are refused and change exactly the fields that the profile checks.

namespace labels
  pod-security.kubernetes.io/enforce=restricted   → violating Pods are rejected
  pod-security.kubernetes.io/warn=restricted      → client sees a warning, object allowed
  pod-security.kubernetes.io/audit=restricted     → audit log annotation, object allowed
  pod-security.kubernetes.io/<mode>-version=v1.35 → pin the rules to a release (or latest)

1. Label a namespace and break a Deployment on purpose

kubectl create namespace prepium-tutorial
kubectl label --overwrite ns prepium-tutorial \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/enforce-version=v1.35 \
  pod-security.kubernetes.io/warn=restricted \
  pod-security.kubernetes.io/warn-version=v1.35
kubectl -n prepium-tutorial create deployment ticker --image=busybox:1.36 -- sleep 3600
kubectl -n prepium-tutorial get deploy,rs,pods

The Deployment is created, and because of the warn label kubectl prints a warning first. Enforcement is applied only to Pods, never to the Deployment or ReplicaSet, so the ReplicaSet exists but no Pod appears. Without a warn label you would get no hint at apply time and would have to read kubectl describe rs events to find the refusal.

2. Turn the message into a checklist

The warning has a documented shape: would violate PodSecurity "restricted:<version>": followed by one entry per failed check, each naming the container and the field it must set. For a stock busybox container you should see four entries, and each maps to one field:

allowPrivilegeEscalation != false   → containers[*].securityContext.allowPrivilegeEscalation: false
unrestricted capabilities           → containers[*].securityContext.capabilities.drop: ["ALL"]
runAsNonRoot != true                → runAsNonRoot: true (Pod level covers every container)
seccompProfile                      → seccompProfile.type: RuntimeDefault (or Localhost)

Restricted also forbids runAsUser: 0, allows adding back only NET_BIND_SERVICE, limits volumes to types such as configMap, secret, emptyDir, projected and persistentVolumeClaim, and inherits every baseline rule. A real workload may trip several of these at once; fix them all, then re-read the message.

3. Apply the fields where they belong

Run kubectl -n prepium-tutorial edit deployment ticker and give the Pod template this shape:

    spec:
      securityContext:
        runAsNonRoot: true
        runAsUser: 10001
        seccompProfile:
          type: RuntimeDefault
      containers:
      - name: busybox          # keep the existing container name
        securityContext:
          allowPrivilegeEscalation: false
          capabilities:
            drop: ["ALL"]

Pod-level runAsNonRoot and seccompProfile satisfy the check for every container; capabilities and escalation exist only per container, including init containers. The explicit non-zero runAsUser matters for a different reason: admission only checks fields, but the kubelet verifies runAsNonRoot at start time. busybox runs as root by default, so without a UID the Pod would be admitted and then its container would refuse to start.

4. Confirm

kubectl -n prepium-tutorial rollout status deployment/ticker
kubectl -n prepium-tutorial get pods
kubectl label --dry-run=server --overwrite ns prepium-tutorial \
  pod-security.kubernetes.io/enforce-version=latest

Changing an enforce label, even in a server-side dry run, makes the admission plugin test every existing Pod in the namespace against the new setting and report violations as warnings. Here it asks whether your Pods would also pass the newest version of the profile; no warnings means they would.

Common mistakes

• Setting capabilities at Pod level. The field does not exist there; strict validation rejects the edit.
• Dropping ALL on the app container but not on an init or sidecar container. One non-compliant container fails the whole Pod.
• Satisfying admission with runAsNonRoot: true on an image whose default user is root, with no UID set. Admitted, then stuck before start.
• Relabelling the namespace to baseline to make the error go away. That changes the policy instead of fixing the workload.

Cleanup: kubectl delete namespace prepium-tutorial. References: Pod Security Standards, Pod Security Admission, Enforce Pod Security Standards with namespace labels. Next, try immutable containers or Pod versus container securityContext.