How to Harden a Kubernetes Pod With a securityContext

Why containers are insecure by default

Without a securityContext, a Kubernetes container runs as root (UID 0), has a writable root filesystem, can acquire new privileges via setuid binaries, and holds the full set of Linux capabilities (including NET_ADMIN, SYS_ADMIN, and others that can break out of weak sandboxes). If the application process is exploited, the attacker starts with maximum access inside the container.

The four fields that matter

Add a securityContext to the container spec in your Deployment manifest:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: worker
spec:
  replicas: 1
  selector:
    matchLabels:
      app: worker
  template:
    metadata:
      labels:
        app: worker
    spec:
      containers:
      - name: worker
        image: busybox:1.36
        command: ["sleep", "86400"]
        securityContext:
          runAsNonRoot: true
          runAsUser: 1000
          allowPrivilegeEscalation: false
          readOnlyRootFilesystem: true
          capabilities:
            drop: ["ALL"]

Apply it and confirm the rollout:

kubectl apply -f deployment.yaml
kubectl rollout status deployment/worker

What each field does

• runAsNonRoot: true - Kubernetes rejects the pod at admission if the container image's default user is root. Pair it with runAsUser: 1000 (a non-zero UID) to set the user explicitly.
• allowPrivilegeEscalation: false - Blocks the no_new_privs kernel flag from being cleared, so setuid/setgid binaries inside the container cannot grant the process more privileges than it started with.
• readOnlyRootFilesystem: true - Mounts the container's root filesystem read-only. An attacker who achieves code execution cannot write tools, backdoors, or modified binaries. If the app needs writable scratch space, mount an emptyDir volume at the specific path.
• capabilities.drop: ["ALL"] - Strips every Linux capability that containers receive by default (CHOWN, NET_BIND_SERVICE, SETUID, etc.). Add back only what the app genuinely needs with capabilities.add.

Verify the hardening

# confirm the container is running as a non-root user
kubectl exec deployment/worker -- id
# uid=1000 gid=0

# confirm the filesystem is read-only
kubectl exec deployment/worker -- touch /test 2>&1
# touch: /test: Read-only file system

Pod Security Standards

These four fields together satisfy the restricted level of Kubernetes Pod Security Standards - the strictest built-in policy. Security audits and compliance tools (kube-bench, Trivy, Checkov) all flag containers missing these settings as high-severity findings. Setting them is the highest-signal, lowest-effort hardening step on any production workload.