Kubernetes Security: Insecure securityContext Capabilities

This page describes a highlighted problem produced by the Docker and Kubernetes Security scanner plugin.

You could find more details on the internal page: Cloud (IaC) Security plugin

If this project has been helpful to you, please consider giving it a ⭐ on GitHub to help others discover it.

What’s the problem with securityContext capabilities?

Overly permissive securityContext capabilities create a common, dangerous misconfiguration in Kubernetes security by granting containers privileges they don’t need, which amplifies the blast radius if an attacker compromises the workload. Adding not-needed Linux capabilities breaks least privilege, weakens isolation boundaries enforced by namespaces and LSMs, and expands the attack surface beyond what most applications require.

The Kubernetes security model expects workloads to minimize or avoid added securityContext capabilities. The Restricted Pod Security Standards enforce hardened defaults across namespaces. In practice, start from no capabilities and add only what is needed after testing. Container runtimes differ in their default capability sets and may include risky items by default.

Note that “ALL” is not a Linux capability. It is a Kubernetes argument used to drop the entire capability set so that only explicitly added capabilities remain

Granting these can allow:

  • Granting these can allow:
  • Control or sniff network traffic (NET_ADMIN, NET_RAW), enabling interface manipulation, firewall/routing changes, and raw/packet socket operations that aid traffic spoofing and packet crafting.
  • Modify or interact with kernel internals (SYS_MODULE, SYS_RAWIO, CAP_BPF, CAP_PERFMON), including loading/unloading modules, performing raw I/O, and elevating eBPF and observability powers on newer kernels.
  • Gain broad system control (SYS_ADMIN, SYS_BOOT), where CAP_SYS_ADMIN covers a wide “kitchen‑sink” range of administrative operations and CAP_SYS_BOOT permits reboot/kexec securityContext capabilities inappropriate for application containers.
  • Bypass mandatory access control policies (MAC_OVERRIDE, MAC_ADMIN), undermining LSM enforcement by overriding or administering MAC decisions

Solution

Follow the least privilege principle:

  • Drop all securityContext capabilities by default (capabilities.drop: “ALL”) to remove the runtime’s default set and start from zero.
  • Add back only specific, necessary capabilities after testing and documenting the requirement. many Restricted implementations allow no additions or, at most, narrowly scoped cases such as NET_BIND_SERVICE
securityContext:
  capabilities:
    drop: ["ALL"]
  runAsNonRoot: true
  allowPrivilegeEscalation: false

Problematic code

apiVersion: v1
kind: Pod
metadata:
    name: test
spec:
      containers:
      - image: nginx:latest
        name: test
      - name : test2
        image : nginx
        securityContext:
          capabilities: 
            add: ["SETPCAP", "MAC_OVERRIDE"]

Verified code

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  containers:
  - name: sec-ctx-demo
    image: busybox
    command: ["sh", "-c", "sleep 1h"]
    securityContext:
      runAsNonRoot: true
      capabilities:
        drop: ["ALL"]

Source of the description: regolibrary.