PodSecurityPolicy non-root image validator

The Incident (What Does the Error Mean?)

Raw error from kubectl describe pod <pod-name>:

Warning  Failed     3s    kubelet  Error: container has runAsNonRoot and image will run as root
                                   (pod: "api-deployment-7d9f8b-xkq2p", container: api-server)

And from kubectl get pod:

NAME                          READY   STATUS             RESTARTS   AGE
api-deployment-7d9f8b-xkq2p   0/1     CrashLoopBackOff   4          2m

What's happening: The kubelet performs a UID check before the container process starts. If runAsNonRoot: true is set and the image's effective UID resolves to 0, the kubelet kills the container immediately — not a graceful rejection, an outright kill. The pod never reaches Running. In Kubernetes 1.25+, with PodSecurity admission replacing the deprecated PodSecurityPolicy, the restricted profile enforces runAsNonRoot: true at the namespace level, meaning every pod in that namespace is subject to this check with no opt-out short of changing the namespace label or fixing the image/spec.

The Attack Vector / Blast Radius

This isn't just a deployment annoyance — the underlying misconfiguration it's preventing is a genuine container escape risk.

If runAsNonRoot were NOT enforced and a root-running container is compromised:

• A process breakout (via a kernel exploit like Dirty Pipe/CVE-2022-0847 or a container runtime vuln) gives the attacker root on the node.
• Root on the node means access to /var/lib/kubelet/pods/ — including mounted Secrets and ServiceAccount tokens for every pod on that node.
• With a valid ServiceAccount token, lateral movement to the Kubernetes API server is trivial. Depending on RBAC, this can mean full cluster compromise.
• In EKS/GKE/AKS, node-level access can expose the IMDS endpoint (169.254.169.254), leaking cloud IAM credentials.

Blast radius of the current CrashLoopBackOff itself:

• Every replica of this deployment is down. If this is a backend service, dependent services are failing. The exponential backoff means recovery time increases with each restart cycle — you're at 5 minutes of backoff after 4 restarts.
• If this is a DaemonSet, every node in the cluster is affected simultaneously.

Prevention in CI/CD

This class of error should never reach a cluster. Gate it at build and deploy time.

1. Checkov — scan Kubernetes manifests in your pipeline

# .github/workflows/security-scan.yml
- name: Checkov K8s Scan
  uses: bridgecrewio/checkov-action@master
  with:
    directory: ./k8s/
    framework: kubernetes
    check: CKV_K8S_6,CKV_K8S_30,CKV_K8S_28
    # CKV_K8S_6  = Do not admit root containers
    # CKV_K8S_30 = Apply security context to pods
    # CKV_K8S_28 = Do not admit containers with allowPrivilegeEscalation

2. OPA/Gatekeeper — enforce at admission with a ConstraintTemplate

apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8srequirenonroot
spec:
  crd:
    spec:
      names:
        kind: K8sRequireNonRoot
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8srequirenonroot
        violation[{"msg": msg}] {
          container := input.review.object.spec.containers[_]
          not container.securityContext.runAsNonRoot
          msg := sprintf("Container '%v' must set securityContext.runAsNonRoot: true", [container.name])
        }
        violation[{"msg": msg}] {
          container := input.review.object.spec.containers[_]
          container.securityContext.runAsUser == 0
          msg := sprintf("Container '%v' must not run as UID 0", [container.name])
        }

3. Trivy in CI — catch root-user images before they're pushed

# Fail the build if the image runs as root
trivy image --exit-code 1 --severity HIGH,CRITICAL \
  --security-checks config \
  my-registry/api-server:${{ github.sha }}

4. Kyverno policy (alternative to Gatekeeper)

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-non-root-user
spec:
  validationFailureAction: Enforce
  rules:
  - name: check-runAsNonRoot
    match:
      resources:
        kinds: [Pod]
    validate:
      message: "Containers must not run as root. Set runAsNonRoot: true and runAsUser > 0."
      pattern:
        spec:
          containers:
          - securityContext:
              runAsNonRoot: true
              runAsUser: ">0"

The fix hierarchy: Dockerfile USER directive → container securityContext.runAsUser → pod securityContext.runAsUser. Fix it at the source (Dockerfile), enforce it at admission (Gatekeeper/Kyverno), and catch drift in CI (Checkov/Trivy). All three layers, not one.