Kubernetes Privileged Pod Options, Node Escape Vectors, and Admission Gating

#Start here: the basics in plain words

A pod is not a tiny virtual machine. It is one or more ordinary Linux processes that the kernel has been told to show less, allow less and give less. Every security-relevant field in a pod spec turns one of those restrictions back off. "Privileged pod options" is the name for the knobs that, once set, leave a workload standing on the node with almost nothing between it and the shared host kernel. The defender's whole job here is to refuse to admit pods that set those knobs, and this page is organised around that: understand each knob, then write the admission rule that blocks it.

Memory hook

"a pod is a process, not a VM." Every escape is the same story: the workload reaches the one shared host kernel because an isolation wall was removed or a kernel bug was reachable. So the defence is always the mirror image: non-root, drop all capabilities, no privileged, no host namespaces, no sensitive host mounts, default seccomp, enforced by Pod Security Admission plus a policy engine. Learn the knobs so you can recognise the pod spec that must never be admitted.

   a hardened pod                              each knob removes one wall
 ┌─────────────────────┐                     privileged: true  → drops nearly every wall at once
 │ non-root UID        │                     hostPID: true     → shares the node's process list
 │ caps: drop ALL      │                     hostNetwork: true → shares the node's network + reaches node-local services
 │ seccomp RuntimeDef. │                     hostPath: /       → mounts the node's root filesystem into the pod
 │ no host namespaces  │                     CAP_SYS_ADMIN     → unlocks many kernel primitives
 │ readOnlyRootFS      │                     a kernel/runtime CVE → one shared kernel, so one bug can be enough
 └─────────────────────┘

#Why it matters

Interviewers use privileged pods to tell apart candidates who treat a container as a magic black-box boundary from those who know it is a process on a shared kernel. The strong answer names the exact kernel mechanism each flag toggles and then shows the admission control that keeps such pods out of production, because in a real cluster the control plane is where you win or lose this. A multi-tenant cluster, or any cluster that runs CI builds, is the case that bites: a workload that can create pods, or set a host flag, or mount a host path, can usually turn that into control of the node and then the other tenants on it.

🎯

On the job. The review question is never "is this container hardened?" in isolation; it is "what stops someone applying a pod that isn't?" If the answer is "we ask people not to", there is no control. The control is admission: Pod Security Admission for the common cases, a ValidatingAdmissionPolicy for the cluster-specific ones.

#SecurityContext vs host namespaces: what each field actually changes

Start with the difference the first interview question always probes: privileged: true versus a single host* flag.

The reassuring part: all five of the above are forbidden by the Baseline Pod Security profile, and Baseline is cheap to turn on. The gaps that need more than Baseline are hostPath scoping and cluster-specific rules, which is why the sections below move from the built-in profiles to a custom ValidatingAdmissionPolicy.

#hostPath and the node filesystem

The pieces you need to knowA hostPath volume mounts a directory or file from the node's own filesystem straight into the pod. The kubelet credentials, the container runtime's control socket, the node's cron and service definitions, and the node's root filesystem all live on that same node filesystem. If a pod can mount a sensitive host path writable, it can influence what the node itself runs as root.

What goes wrongWrite access to the node's root filesystem, or to the runtime's control socket, lets a workload ask the node (as root) to do things on its behalf: schedule a privileged task, or launch another container with the node's filesystem attached. The common theme is that hostPath turns "I control a pod" into "I control what the node runs", because the pod and the node are now sharing files.

Why it's badThe node runs every other tenant's pods. Reaching the node from one pod means reaching all of them. This is why hostPath is forbidden entirely by Baseline, and why, when a cluster genuinely needs a host mount (a log shipper reading /var/log), you want a rule that allows only that one prefix and nothing else.

🎯

On the job. The highest-value single admission rule on a shared cluster is "no hostPath, except read-only under an explicit allow-list of prefixes like /var/log/". A request to mount /, /etc, /var/run, or a runtime socket path is the finding. The lab below shows a policy enforcing exactly this, live.

#Container breakout mechanics, explained from zero

These are the named escapes an interviewer expects you to recognise. The goal here is to understand the mechanism and the fix, so you can reason about which admission rule or kernel version removes each one. None of this is a recipe; it is the defender's model of why the wall failed.

#cgroup v1 release_agent — CVE-2022-0492

The pieces you need to knowA cgroup is a group of processes the kernel accounts and limits together. In the old cgroup v1 design, a cgroup could have a release_agent: a path to a program the kernel runs, as root on the host, when the last process in that cgroup exits. That feature existed to let the system clean up after a cgroup emptied.

What went wrongA kernel check was missing (cgroup_release_agent_write in kernel/cgroup/cgroup-v1.c, tracked as CVE-2022-0492, CWE-862 Missing Authorization). Under the right conditions a process could set the release_agent path without the capability that should have been required. Because the kernel runs that program on the host as root, a workload that could both set the path and trigger the cgroup to empty got the host to execute a program of its choosing with root.

Why it's bad and what removes it. It turned a container with the wrong settings into root on the node. Three things each independently shut it down: the kernel fix added the missing capability check (upstream commit 24f6008564183a…); cgroup v2 redesigned release notifications so there is no host-side release_agent program to point at, so the whole class disappears on a cgroup-v2 node; and an LSM such as SELinux in enforcing mode blocked the escape on distributions that ship it (Red Hat rated it CVSS 7.0, NVD 7.8). The defender's lesson: run cgroup v2 (the modern default), and do not grant the capabilities and host mounts the attack needed in the first place.

📰

Real incident — CVE-2022-0492 (2022). The release_agent flaw was reachable from a container that had CAP_SYS_ADMIN or could write the relevant cgroup files, and it became a widely-cited container-escape demonstration. The lesson that stuck: features that let an unprivileged side name a program the kernel runs as root are a recurring escape shape, and cgroup v2 plus least-privilege containers close it.

#runc working-directory file-descriptor leak — CVE-2024-21626

The pieces you need to knowrunc is the low-level runtime that actually starts containers. When it sets up a container it briefly holds open file descriptors to host resources, including the host's /sys/fs/cgroup.

What went wrongThose descriptors leaked into the container's first process (CVE-2024-21626, affecting runc >=1.0.0-rc93 and <=1.1.11, fixed in 1.1.12, CVSS up to 8.6). If a container image set its working directory to a path pointing through one of the leaked descriptors, the container's process started with a working directory that was actually in the host's filesystem, outside the container. A crafted image could disguise this with an innocent-looking symlink.

Why it's bad and what removes it. A working directory on the host filesystem is a doorway from the container into the host, and variants could overwrite host binaries, giving node control. The fix shipped in runc 1.1.12. The defender's lesson: patch the runtime (this is a "keep runc current" item), and run only trusted images, because the trigger lived inside the image.

#BuildKit entitlement and cache-mount flaws — CVE-2024-23651 / CVE-2024-23653

The pieces you need to knowBuildKit is the engine behind modern docker build. It runs build steps, and some capabilities (like running a step with elevated privileges) are gated behind an entitlement you must explicitly enable (security.insecure).

What went wrongTwo 2024 flaws, both fixed in BuildKit v0.12.5:

Why it's bad and what removes it. CI runners build untrusted Dockerfiles all day; a build that can grab host files or run a privileged container is a runner compromise. Both are fixed in v0.12.5, and the published workaround is to not accept BuildKit frontends from untrusted sources and to avoid building untrusted Dockerfiles that use cache mounts. The defender's lesson ties straight to build platform security: keep BuildKit patched, run builds rootless and sandboxed, and never hand a CI builder privileged: true or a mounted runtime socket.

Important

Notice the pattern across all four: each was fixed by a version bump and was avoidable by least privilege (no CAP_SYS_ADMIN, cgroup v2, no host mounts, no privileged builds). You rarely rely on a single mitigation. Patch and refuse the dangerous pod spec.

#Hardening CI builders without privileged pods

The usual reason teams reach for privileged: true is "we need to build container images in the cluster". You do not need privileged for that any more.

🎯

On the job. If a build pipeline sets privileged: true "so Docker works", the fix is rootless BuildKit, and it is a drop-in change for most builds. Flag the privileged flag and the socket mount together; they are the two tells of a builder that trusts its workload too much.

#Pod Security Admission: the built-in first line

What it isPod Security Admission (PSA) is a built-in admission controller that enforces the three Pod Security Standards profiles by namespace label. It replaced the removed PodSecurityPolicy (PSP) in Kubernetes 1.25.

Each profile runs in up to three modes at once, set per namespace: enforce (reject violating pods), audit (record them in the audit log) and warn (return a warning to whoever applied it). A common safe rollout is enforce at baseline, warn and audit at restricted, so you block the dangerous pods immediately while surfacing what would need to change to reach restricted.

In practiceLabelling a namespace and then trying a host-namespace pod shows the enforcement and the warning together (real output from the cluster security lab):

$ kubectl label ns psa-demo \
    pod-security.kubernetes.io/enforce=baseline \
    pod-security.kubernetes.io/warn=restricted \
    pod-security.kubernetes.io/audit=restricted
namespace/psa-demo labeled

$ kubectl -n psa-demo apply -f hostpid-pod.yaml
Error from server (Forbidden): pods "hostpid" is forbidden:
  violates PodSecurity "baseline:latest": host namespaces (hostPID=true)   ← enforced: rejected

$ kubectl -n psa-demo apply -f plain-pod.yaml
Warning: would violate PodSecurity "restricted:latest": allowPrivilegeEscalation != false,
  unrestricted capabilities, runAsNonRoot != true, seccompProfile              ← warned, still created
pod/plain created

PSA's gapsPSA is namespace-coarse and profile-fixed. It cannot express "hostPath is allowed, but only under /var/log", it cannot vary a rule by image or team, and whoever can set namespace labels (or create a namespace) can downgrade the profile. For anything cluster-specific you reach for a policy engine.

📰

Real incident — PodSecurityPolicy removal (Kubernetes 1.25, 2022). PSP, the original built-in, was deprecated in 1.21 and removed in 1.25 because its authorisation model was confusing and it was hard to roll out safely. Clusters that had leaned entirely on PSP had to migrate to PSA or a third-party admission engine. The lesson: build your pod-admission policy on a supported, testable mechanism, and expect to layer PSA with a CEL policy or an engine like Kyverno or Gatekeeper.

#ValidatingAdmissionPolicy: cluster-specific rules in CEL, no webhook

What it isA ValidatingAdmissionPolicy (VAP) lets you write admission rules in CEL (Common Expression Language) that the API server evaluates in-process, with no external webhook to run, secure and keep available. It went stable (admissionregistration.k8s.io/v1) in Kubernetes 1.30. This is how you express the rules PSA cannot: scoped hostPath, deny host namespaces cluster-wide, block runtime-socket mounts, require a RuntimeClass for a given namespace.

A policy has two parts: the ValidatingAdmissionPolicy (the CEL rules) and a ValidatingAdmissionPolicyBinding (where they apply, and whether failures Deny, Warn or Audit). CEL expressions see object (the incoming resource), oldObject, request, params (an optional parameter resource) and namespaceObject.

In practiceThis policy denies host namespaces, blocks every hostPath except read paths under /var/log/, and rejects privileged containers. It is bound everywhere except the system namespaces, with Deny and Audit:

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata: {name: deny-host-access}
spec:
  failurePolicy: Fail                       # ← if the policy can't evaluate, fail closed
  matchConstraints:
    resourceRules:
    - apiGroups: [""]
      apiVersions: ["v1"]
      operations: ["CREATE","UPDATE"]
      resources: ["pods"]
  validations:
  - expression: "!(object.spec.?hostPID.orValue(false) || object.spec.?hostNetwork.orValue(false) || object.spec.?hostIPC.orValue(false))"
    message: "host namespaces (hostPID/hostNetwork/hostIPC) are not allowed"
  - expression: "!has(object.spec.volumes) || object.spec.volumes.all(v, !has(v.hostPath) || v.hostPath.path.startsWith('/var/log/'))"
    message: "hostPath volumes are only allowed under /var/log/"       # ← the rule PSA can't express
  - expression: "object.spec.containers.all(c, !has(c.securityContext) || !has(c.securityContext.privileged) || !c.securityContext.privileged)"
    message: "privileged containers are not allowed"
---
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicyBinding
metadata: {name: deny-host-access}
spec:
  policyName: deny-host-access
  validationActions: [Deny, Audit]          # ← reject, and record in the audit log
  matchResources:
    namespaceSelector:
      matchExpressions:
      - {key: kubernetes.io/metadata.name, operator: NotIn, values: [kube-system, local-path-storage]}

Applied to the lab cluster, it rejects a pod that mounts the node root and admits one that mounts only /var/log/pods:

$ kubectl -n vap-demo apply -f hostroot-pod.yaml          # mounts hostPath: /
The pods "hostroot" is invalid: ValidatingAdmissionPolicy 'deny-host-access'
  denied request: hostPath volumes are only allowed under /var/log/     ← rejected

$ kubectl -n vap-demo apply -f logs-pod.yaml              # mounts hostPath: /var/log/pods
pod/logs created                                                        ← allowed

The Audit action writes the rejection into the API-server audit log, which is where your detection picks it up:

{ "verb": "create",
  "requestURI": "/api/v1/namespaces/vap-demo/pods?fieldValidation=Strict",
  "responseStatus": { "code": 422, "status": "Failure",
    "message": "...denied request: hostPath volumes are only allowed under /var/log/" },
  "annotations": {
    "validation.policy.admission.k8s.io/validation_failure":
      "[{\"message\":\"hostPath volumes are only allowed under /var/log/\",\"policy\":\"deny-host-access\",\"binding\":\"deny-host-access\",\"validationActions\":[\"Deny\",\"Audit\"]}]"   ← alert on this
  } }

Tip

See it yourselfThe cluster security lab builds a real kind cluster with API-server audit logging and walks the RBAC + hostPath privesc path, Pod Security Admission blocking it, and a RuntimeClass routing an untrusted pod to a gVisor handler. The PSA and VAP output above was captured from it.

🎯

On the job. Prefer a ValidatingAdmissionPolicy over an external validating webhook when you can: no extra service to run, no availability or certificate to manage, and a webhook that is down forces you to choose between failing open (no policy) or failing closed (no deploys). Keep the webhook only for logic CEL cannot express. Set failurePolicy: Fail so a policy that cannot evaluate rejects rather than waves the pod through, and alert on the validation.policy.admission.k8s.io/validation_failure audit annotation, since a burst of those is someone probing what they are allowed to schedule.