Kubernetes · Orchestration under pressure

How do you harden a pod with securityContext?

Hardsecurity-contextpod-securityhardeningUpdated Oct 2026

Short answer

Set runAsNonRoot, drop Linux capabilities, disable privilege escalation, use a read-only root filesystem and apply seccomp. Enforce the baseline with Pod Security Admission.

securityContext exists at pod and container level. Pod-level settings apply defaults; container-level settings override them. The goal is to reduce what a compromised process can do: no root, no new privileges, no write access to the image filesystem, and a minimal capability set.

runAsNonRoot: true and a fixed runAsUser avoid accidental root
allowPrivilegeEscalation: false blocks setuid and similar paths
Drop ALL capabilities and add back only what is required
readOnlyRootFilesystem forces explicit writable mounts
seccompProfile: RuntimeDefault filters dangerous syscalls

yaml

securityContext:
  runAsNonRoot: true
  runAsUser: 10001
  seccompProfile:
    type: RuntimeDefault
  containers:
    - name: api
      image: registry.example.com/api:1.5.0
      securityContext:
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
        capabilities:
          drop: ["ALL"]
      volumeMounts:
        - name: tmp
          mountPath: /tmp
  volumes:
    - name: tmp
      emptyDir: {}

Use Pod Security Admission labels on namespaces to enforce baseline or restricted profiles. Start with warn and audit, fix workloads, then enforce. Admission catches manifests that bypass review, but it does not replace image scanning, runtime detection or network policy.

Some images write to their root filesystem at startup. A read-only root filesystem will break them unless you mount writable emptyDir volumes for the paths they need. Test this before enforcing cluster-wide.

Follow-ups you should expect

Interviewers use these to check whether the first answer was understanding or memorisation.

1What is the difference between pod-level and container-level securityContext?
2Why is allowPrivilegeEscalation important?
3How would you roll out restricted Pod Security Admission safely?
4What does a read-only root filesystem break?

Say it in the interview

I harden pods by running as non-root, disabling privilege escalation, dropping all capabilities, using a read-only root filesystem and enabling the default seccomp profile. I enforce the baseline with Pod Security Admission, starting in warn and audit mode so I can find broken workloads before enforcing. These controls limit blast radius but do not replace image scanning, network policy or runtime detection. I test writable-path requirements because read-only roots often expose hidden assumptions.

Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.

Now say it out loud.

Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live Kubernetes mock interview and get scored feedback on depth, clarity and confidence.

Start a free Kubernetes interview Browse all questions

Follow-ups you should expect

Related questions

Now say it out loud.