Capabilities and Read-Only Root Filesystem

Running as a non-root UID is a strong first step. But a process that runs as UID 1000 can still hold Linux capabilities inherited from the container runtime. And a process without any dangerous capabilities can still write malware to its own filesystem if it gets compromised. Two container-level fields address these remaining attack surfaces: capabilities and readOnlyRootFilesystem. Together with allowPrivilegeEscalation: false, they form the practical hardening checklist for a container.

Linux capabilities in practice

Recall from the first lesson that Linux capabilities break root into discrete privileges. The container runtime grants a default set when it starts a container. That set typically includes CAP_NET_RAW (raw socket access), CAP_CHOWN (change file ownership), CAP_SETUID, CAP_SETGID, and around a dozen others. Most applications need none of them.

The recommended pattern is: drop all capabilities first, then add back only the ones the application genuinely needs. This is the principle of least privilege applied at the kernel level.

nano hardened-pod.yaml

Start with the drop-all baseline:

apiVersion: v1
kind: Pod
metadata:
  name: hardened-pod
spec:
  containers:
    - name: app
      image: nginx:1.28
      securityContext:
        capabilities:
          drop:
            - ALL

kubectl apply -f hardened-pod.yaml

kubectl describe pod hardened-pod

In the Security Context block, look for Drop: [ALL]. That single entry tells the runtime to strip every capability from the container before it starts. If the application needs to bind to a port below 1024, you would add NET_BIND_SERVICE back:

# illustrative only
securityContext:
  capabilities:
    drop:
      - ALL
    add:
      - NET_BIND_SERVICE

allowPrivilegeEscalation: blocking setuid

Even without dangerous capabilities, a container can escalate privileges through setuid binaries, programs that run with the owner’s permissions rather than the caller’s. allowPrivilegeEscalation: false prevents any process in the container from gaining more privileges than its parent process holds. It blocks setuid and setgid execution at the kernel level.

Add it to the manifest:

nano hardened-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: hardened-pod
spec:
  containers:
    - name: app
      image: nginx:1.28
      securityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop:
            - ALL

kubectl apply -f hardened-pod.yaml

This field is container-level only, for the same reason capabilities are container-level: it is a per-process property, not a pod-wide policy.

readOnlyRootFilesystem: removing the writable surface

Now consider a different threat. An attacker achieves remote code execution inside your container. They want to install a persistent backdoor or download additional tools. If the container’s root filesystem is writable, they can. If it is not, they cannot.

readOnlyRootFilesystem: true mounts the container’s root filesystem as read-only. Writes fail immediately. The process can still read every file, but cannot create, modify, or delete anything on the root filesystem.

Add it to the manifest:

nano hardened-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: hardened-pod
spec:
  containers:
    - name: app
      image: nginx:1.28
      securityContext:
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
        capabilities:
          drop:
            - ALL

kubectl apply -f hardened-pod.yaml

kubectl describe pod hardened-pod

The describe output will show Read Only Root Filesystem: true under the container’s security context.

The complete hardened manifest

Here is the fully assembled hardened Pod spec with all three container-level fields applied:

nano hardened-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: hardened-pod
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    runAsGroup: 2000
  containers:
    - name: app
      image: nginx:1.28
      securityContext:
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
        capabilities:
          drop:
            - ALL

kubectl apply -f hardened-pod.yaml

kubectl describe pod hardened-pod

Reading the describe output from top to bottom gives you the full security posture: the pod-level UID and GID, then per-container the capability set, the privilege escalation block, and the filesystem mode. That is the complete picture.

You now have the complete security context toolkit for container hardening: identity fields at the pod level, and capability, escalation, and filesystem restrictions at the container level. The next module moves from runtime security to image security, examining where container images come from, how to verify them, and how to control which images are allowed to run in a cluster.