Security, RBAC, and Production ReadinessLesson 6.3

Kubernetes security contexts: running pods with least privilege

Pod security context, container security context, runAsNonRoot, runAsUser, readOnlyRootFilesystem, allowPrivilegeEscalation, capabilities drop, privileged containers, seccompProfile

Containers Are Not Secure by Default

Kubernetes Pod security context hardening checklist

By default, containers run as root and have a writable filesystem with full Linux capabilities. A compromised container can potentially escape to the host. Security contexts let you restrict what a container can do.

Hardened Pod Security Context

apiVersion: v1
kind: Pod
spec:
  securityContext:
    runAsNonRoot: true         # fail if image runs as root
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000              # volume mounts are owned by this group
  containers:
  - name: app
    image: my-app:2.0
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop: ["ALL"]          # remove all Linux capabilities
        add: ["NET_BIND_SERVICE"]  # add back only if needed
    volumeMounts:
    - name: tmp
      mountPath: /tmp          # provide a writable tmp if needed
  volumes:
  - name: tmp
    emptyDir: {}

Use readOnlyRootFilesystem: true by default. If the app writes to disk, mount an emptyDir for the specific path instead of making the whole filesystem writable. This limits blast radius on compromise.