Container runtime restrictions: remove privileges a service does not use

Last updated: 1 Oct 20266 min read

tutorial

A Kubernetes security context controls privileges and access for a Pod or container. Running as a non-root user, disallowing privilege escalation, dropping Linux capabilities, using a read-only root filesystem, and selecting a seccomp profile reduce what compromised code can do. They do not repair a vulnerable dependency or make a leaked credential harmless.

Operational decision

An invoice renderer writes temporary PDFs to a mounted scratch directory, not to its image filesystem. Start the container with the restrictive settings below in a test namespace, then exercise font loading, temporary file creation, and a full PDF render. The fragment belongs inside one container specification and assumes its image can run with the selected user ID. Grant a bounded writable volume only for the scratch path; do not reopen the entire root filesystem because one library expects a cache directory. Confirm that the service account token is unnecessary and disable its automatic mount when possible. Test on the runtime used in production because the RuntimeDefault seccomp profile can differ by container runtime.

securityContext:
  runAsNonRoot: true
  runAsUser: 10473
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities:
    drop: [ALL]
  seccompProfile:
    type: RuntimeDefault

Cost and verification

Restrictive settings can expose hidden writes and syscall dependencies during migration. That test work is cheaper than discovering them during an incident rollout, but it needs representative rendering inputs. A read-only image may shift temporary data into memory-backed storage, which still consumes node resources. Watch memory and ephemeral storage after the change. Runtime restrictions are one layer; image provenance, network policy, RBAC, and secret handling remain separate controls.

Common Mistakes

Do not add privileged mode to fix one missing cache directory.
Do not assume runAsNonRoot proves the image is safe.
Do not omit application tests on the actual container runtime.

Connected lessons

Advanced follow-up

devops

resilience