Restrict privileged Kubernetes containers

The fix

spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 10001
    seccompProfile: { type: RuntimeDefault }
  containers:
    - name: app
      securityContext:
        allowPrivilegeEscalation: false
        privileged: false
        readOnlyRootFilesystem: true
        capabilities:
          drop: ["ALL"]

Enforcing this by hand on every pod is error-prone; let Pod Security Admission require it and use this as the spec that passes restricted.

Why it matters

A container is isolated from its node by namespaces, capabilities, seccomp and the user it runs as — the same mechanisms as Docker, because it’s the same runtime underneath. A pod that requests its way out of those is a route to the node, and a node is every pod scheduled on it plus a kubelet credential.

The dangerous requests, worst first:

• privileged: true — disables the isolation entirely, exposes host devices. The container can mount the host disk. This is the Docker --privileged problem with a Kubernetes wrapper.
• hostPID, hostNetwork, hostIPC — share the node’s process, network or IPC namespace. hostNetwork puts the pod on the node’s network, past network policies and onto the metadata service.
• hostPath volumes — mount a node directory into the pod. hostPath: / is the node’s filesystem; even /var/run/docker.sock or the kubelet’s directory is a route to node control.
• Running as root (runAsUser: 0, the default) — a container escape lands as root on the node instead of an unprivileged user.
• allowPrivilegeEscalation: true (the default) — a setuid binary inside the container can re-elevate even after you’ve dropped to a non-root user.

The hardened securityContext, line by line

Setting	Effect
runAsNonRoot: true	Refuse to start if the image runs as root
runAsUser: 10001	A specific unprivileged UID
allowPrivilegeEscalation: false	No re-elevation via setuid (no_new_privs)
readOnlyRootFilesystem: true	Can’t write a payload into the container
capabilities.drop: ["ALL"]	Start from zero, add back only what’s needed
seccompProfile.type: RuntimeDefault	Block the syscalls the runtime’s profile blocks

RuntimeDefault seccomp is worth calling out — Kubernetes does not apply a seccomp profile by default (historically Unconfined), so unless you set this, the container can make every syscall. It’s one line and it closes a lot.

Pod vs container level

Some settings live on the pod securityContext (runAsNonRoot, runAsUser, seccompProfile, fsGroup), some on the container (allowPrivilegeEscalation, readOnlyRootFilesystem, capabilities, privileged). Container-level overrides pod-level. Set both, and don’t assume a pod-level runAsNonRoot covers a container that sets its own.

Verify it worked

Find privileged and host-namespace pods — the highest-risk ones:

kubectl get pods -A -o json | jq -r '.items[] |
  select(
    (.spec.containers[].securityContext.privileged == true) or
    .spec.hostPID or .spec.hostNetwork or .spec.hostIPC
  ) | "\(.metadata.namespace)/\(.metadata.name)"' | sort -u

Find hostPath mounts — each is a window into the node:

kubectl get pods -A -o json | jq -r '.items[] |
  select(.spec.volumes[]?.hostPath) |
  "\(.metadata.namespace)/\(.metadata.name): \(.spec.volumes[] | select(.hostPath) | .hostPath.path)"'

hostPath: /, /var/run/docker.sock, or a kubelet path is a serious finding.

Find pods running as root or allowing escalation:

kubectl get pods -A -o json | jq -r '.items[] |
  select((.spec.securityContext.runAsNonRoot != true) and
         (.spec.containers[].securityContext.runAsNonRoot != true)) |
  "\(.metadata.namespace)/\(.metadata.name)"' | sort -u | head -30

Then prove the hardening on a specific pod — from inside it, escalation should fail:

kubectl exec -n orders deploy/app -- id            # expect uid=10001, not 0
kubectl exec -n orders deploy/app -- sh -c 'touch /test' 2>&1   # expect read-only fs

Before you apply this

A hardened securityContext breaks images that assume root — which is a large share of older images, and the breakage is at pod startup with an error like container has runAsNonRoot and image will run as root.

The common breakages and fixes:

• runAsNonRoot: true on a root image — the image needs rebuilding to run as a non-root user, or you need runAsUser pointing at a UID the image’s files are owned by. Some official images have -unprivileged variants for exactly this.
• readOnlyRootFilesystem: true breaks anything that writes outside a volume — temp files, caches, pidfiles, unix sockets. Add an emptyDir volume mounted at each writable path (/tmp, the cache dir) rather than giving up the read-only root.
• capabilities.drop: ["ALL"] breaks a container that binds a low port or de-escalates at startup. Bind a high port and map it, or add back the one capability with capabilities.add.

Roll it out with Pod Security Admission in warn/audit mode first — that tells you exactly which running pods would fail restricted before anything breaks, which is far better than discovering it pod by pod.

Don’t set privileged: false and stop. The dangerous requests are a family — hostPath, hostNetwork, host namespaces, root, escalation — and closing only privileged leaves the others open. This is why enforcing the restricted standard is better than hand-checking one field: it covers the whole family at once.

Some workloads legitimately need node access — a CNI plugin, a CSI driver, a node-exporter, a log collector reading /var/log. Those belong in their own namespace with a baseline or privileged PSA label and a tight RBAC scope, not blanket-hardened into failure.

Related

• Pod Security Admission — enforce this automatically instead of per-pod.
• Network policies — contain a pod that is compromised anyway.