Minimize The Admission Containers With Capabilities Assigned

Manual Steps

On any machine with kubectl access, list all namespaces and identify those that should be “locked down” (no workloads needing Linux capabilities), for example dev/test or simple stateless apps:
kubectl get ns --show-labels
Optionally label target namespaces for easier selection:
kubectl label ns <namespace> security.capabilities=restricted

For each candidate namespace, inspect all running workloads for explicit capability use in securityContext:

# Pods
kubectl get pods -n <namespace> -o yaml | grep -nE 'capabilities|allowPrivilegeEscalation|privileged'

# Workloads (Deployments, DaemonSets, StatefulSets, Jobs, CronJobs)
kubectl get deploy,ds,sts,job,cronjob -n <namespace> -o yaml | grep -nE 'capabilities|allowPrivilegeEscalation|privileged'

If any container uses securityContext.capabilities.add or runs privileged / with allowPrivilegeEscalation: true, confirm with the app owner whether this is truly required.

For containers that do not require capabilities, plan to standardize on dropping all capabilities, either at the pod spec or via a restrictive Pod Security configuration. Example pod-level setting to recommend to app owners:
securityContext: runAsNonRoot: true allowPrivilegeEscalation: false capabilities: drop: - ALL

If your cluster still uses PodSecurityPolicy and it is enabled, create or select a PSP that requires dropping all capabilities and denies additional ones, and bind it only to namespaces whose workloads do not need capabilities. Example PSP manifest to adapt and apply:

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: drop-all-caps
spec:
  privileged: false
  allowPrivilegeEscalation: false
  requiredDropCapabilities:
    - ALL
  allowedCapabilities: []
  volumes:
    - 'configMap'
    - 'emptyDir'
    - 'projected'
    - 'secret'
    - 'downwardAPI'
    - 'persistentVolumeClaim'
  runAsUser:
    rule: 'MustRunAsNonRoot'
  seLinux:
    rule: 'RunAsAny'
  fsGroup:
    rule: 'MustRunAs'
    ranges:
      - min: 1
        max: 65535
  supplementalGroups:
    rule: 'MustRunAs'
    ranges:
      - min: 1
        max: 65535

Then bind it to service accounts in the target namespace:

kubectl create role psp:drop-all-caps --verb=use --resource=podsecuritypolicies.policy --resource-name=drop-all-caps -n <namespace>
kubectl create rolebinding psp:drop-all-caps \
  --role=psp:drop-all-caps \
  --serviceaccount=<namespace>:default \
  -n <namespace>

If PSP is not available (or you are on newer Kubernetes), use Pod Security Admission / Pod Security Standards or an equivalent policy engine (e.g., OPA Gatekeeper, Kyverno) to enforce “drop all capabilities” on selected namespaces. For Pod Security Admission, set namespaces to a strict level and then verify the effect:

kubectl label ns <namespace> pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/enforce-version=latest --overwrite

# Attempt to admit a pod that adds capabilities; it should be rejected
kubectl apply -n <namespace> -f - <<'EOF'
apiVersion: v1
kind: Pod
metadata:
  name: test-add-cap
spec:
  containers:
    - name: c
      image: alpine
      command: ["sleep","3600"]
      securityContext:
        capabilities:
          add: ["NET_ADMIN"]
EOF

Re‑audit periodically to ensure no capability use has crept back into “locked down” namespaces, and that your policy is correctly preventing admission:

# Check for capabilities in all pods in locked-down namespaces
kubectl get ns -l security.capabilities=restricted -o jsonpath='{range .items[*]}{.metadata.name}{"\n"}{end}' \
| xargs -I{} sh -c 'echo "Namespace: {}"; kubectl get pods -n {} -o yaml | grep -nE "capabilities|privileged|allowPrivilegeEscalation" || echo "  No explicit capabilities found"'

Using kubectl

Run these from any machine with kubectl access.

1. List all pods and surface explicit capabilities

kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{";"}{.metadata.name}{";"}{range .spec.containers[*]}{.name}{";"}{.securityContext.capabilities}{"|"}{end}{"\n"}{end}' \
| column -s';' -t

What indicates a problem:

Any container showing add: [...] with capabilities (for example CAP_SYS_ADMIN, CAP_NET_ADMIN, CAP_SYS_PTRACE) in namespaces that are not known to need them.
Containers with no drop list, or that don’t include ALL in drop, especially when add is present.

2. Inspect full securityContext for specific namespaces

Review “application” namespaces (replace with your namespaces):

kubectl get pods -n default -o yaml | less
kubectl get pods -n production -o yaml | less

In each pod, look under .spec.containers[].securityContext.capabilities and note:

add: entries: which capabilities are being granted.
drop: entries: whether ALL is dropped or only some caps.

Problem indicators:

Capabilities added without a clear, documented need.
Security context missing entirely for workloads that may rely on defaults you do not control.

3. Check for PodSecurityPolicy (or replacement) enforcing dropped capabilities

If PSP is still in use:

kubectl get psp -o yaml | less

Look for:

spec.requiredDropCapabilities including ALL, or a broad set of drops.
spec.allowedCapabilities being empty or very restricted.

Problem indicators:

No PSPs present.
PSPs that allow broad capabilities (allowedCapabilities: ["*"] or many capabilities) and are bound to general-purpose namespaces.

If using Pod Security Admission (PSA) labels instead of PSP:

kubectl get ns --show-labels

Problem indicators:

Application namespaces without restrictive pod security labels (for example, not set to restricted) while workloads in them are using elevated capabilities.

4. Map which PSPs (if any) apply to a namespace

If RBAC + PSP are used, list role bindings in a namespace:

kubectl get rolebindings,clusterrolebindings -n default -o yaml | less

Look for:

ClusterRole or Role that references a PSP.
Which service accounts in the namespace are bound to permissive PSPs.

Problem indicators:

Service accounts in a namespace bound (directly or indirectly) to highly permissive PSPs while workloads do not need extra capabilities.

5. Spot risky capabilities via label/annotation search

Search for pods likely using custom security settings:

kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{" "}{.metadata.name}{" "}{.metadata.annotations}{"\n"}{end}' | grep -i security

Then examine interesting pods in detail:

kubectl get pod <pod-name> -n <namespace> -o yaml | less

Problem indicators:

Annotations or settings that explicitly relax security controls while the application does not clearly require them.

6. Human review guidance

Use the above data to decide, per namespace:

Does any workload in this namespace truly require Linux capabilities (for example, low-level networking, mounting filesystems, time sync, etc.)?
If no, this namespace is a good candidate to:
- Ensure workloads drop all capabilities, and
- Attach policies (PSP or its replacement) that forbid adding capabilities / require dropping all.

There is no single kubectl command to decide this automatically; it requires understanding what each application does and whether the capabilities are strictly necessary.

Automation

#!/usr/bin/env bash
# Report pods and workloads that use Linux capabilities, per namespace.
# Run on: any machine with kubectl access and a current context.

set -euo pipefail

echo "=== 1) Namespaces and whether they enforce dropping all capabilities (PodSecurityPolicy) ==="
echo "NOTE: PSP is deprecated/removed in recent Kubernetes; skip this section if not in use."
echo

# List PSPs that require all capabilities to be dropped
echo "# PodSecurityPolicies that enforce 'drop: [ALL]' (good controls to bind to non-privileged namespaces):"
kubectl get psp -o json 2>/dev/null | jq -r '
  .items[]
  | select(
      (.spec.requiredDropCapabilities // []) as $req
      | ($req | index("ALL")) != null
    )
  | "- " + .metadata.name
' || echo "PSP API not available or jq not installed; skip PSP analysis."

echo
echo "=== 2) Pods with capabilities in their securityContext (per namespace) ==="
echo

# Show per-pod container capabilities
kubectl get pods -A -o json | jq -r '
  .items[]
  | {
      ns: .metadata.namespace,
      pod: .metadata.name,
      containers: (
        [.spec.containers[]? | {
          name,
          cap_add:   (.securityContext.capabilities.add   // []),
          cap_drop:  (.securityContext.capabilities.drop  // [])
        }]
        +
        [.spec.initContainers[]? | {
          name,
          cap_add:   (.securityContext.capabilities.add   // []),
          cap_drop:  (.securityContext.capabilities.drop  // [])
        }]
      )
    }
  | select(
      ([.containers[]?.cap_add[]?] | length) > 0
      or
      (
        # has capabilities block but does *not* drop ALL
        ([.containers[]?.cap_drop[]?] | length) > 0
        and
        (([.containers[]?.cap_drop[]?] | index("ALL")) == null)
      )
    )
  | "NAMESPACE: \(.ns)\nPOD: \(.pod)\n" +
    (
      .containers[]
      | "  container: \(.name)\n" +
        "    add:  \(.cap_add | join(\", \"))\n" +
        "    drop: \(.cap_drop | join(\", \"))\n"
    )
  + "---"
'

echo
echo "=== 3) Deployments/DaemonSets/StatefulSets with capabilities in their pod templates ==="
echo

for kind in deployment daemonset statefulset; do
  echo "# ${kind^}s with capabilities configured:"
  kubectl get "$kind" -A -o json | jq -r "
    .items[]
    | {
        kind: \"${kind^}\",
        ns: .metadata.namespace,
        name: .metadata.name,
        containers: (
          [.spec.template.spec.containers[]? | {
            name,
            cap_add:   (.securityContext.capabilities.add   // []),
            cap_drop:  (.securityContext.capabilities.drop  // [])
          }]
          +
          [.spec.template.spec.initContainers[]? | {
            name,
            cap_add:   (.securityContext.capabilities.add   // []),
            cap_drop:  (.securityContext.capabilities.drop  // [])
          }]
        )
      }
    | select(
        ([.containers[]?.cap_add[]?] | length) > 0
        or
        (
          ([.containers[]?.cap_drop[]?] | length) > 0
          and
          (([.containers[]?.cap_drop[]?] | index(\"ALL\")) == null)
        )
      )
    | \"NAMESPACE: \(.ns)\nKIND: \(.kind)\nNAME: \(.name)\n\" +
      (
        .containers[]
        | \"  container: \(.name)\n\" +
          \"    add:  \(.cap_add | join(\", \"))\n\" +
          \"    drop: \(.cap_drop | join(\", \"))\n\"
      )
    + \"---\"
  "
  echo
done

echo "=== 4) Interpretation ==="
cat <<'EOF'
Problematic output to review:

- Any pod or workload where:
  * 'add' lists one or more capabilities (e.g. NET_ADMIN, SYS_ADMIN), OR
  * 'drop' does not contain 'ALL' (i.e., capabilities are not fully dropped).

From the benchmark perspective, namespaces that run applications which do NOT need
Linux capabilities should:
  - Have no pods/workloads in the reports above, and
  - Be governed by a policy (e.g. PSP, or equivalent admission policy) that forbids
    admission of containers unless they drop ALL capabilities.

Use the namespace information in the reports to decide where to tighten policy,
and which workloads may need exceptions because they legitimately require capabilities.
EOF

AWS Introduction

AWS Pricing

AWS Threats

AWS Misconfigurations

Minimize The Admission Containers With Capabilities Assigned

More Info:

Risk Level

Address

Compliance Standards

Triage and Remediation

Remediation

Using kubectl

1. List all pods and surface explicit capabilities

2. Inspect full securityContext for specific namespaces

3. Check for PodSecurityPolicy (or replacement) enforcing dropped capabilities

4. Map which PSPs (if any) apply to a namespace

5. Spot risky capabilities via label/annotation search

6. Human review guidance

Additional Reading:

​More Info:

​Risk Level

​Address

​Compliance Standards

​Triage and Remediation

​Remediation

​Using kubectl

​1. List all pods and surface explicit capabilities

​2. Inspect full securityContext for specific namespaces

​3. Check for PodSecurityPolicy (or replacement) enforcing dropped capabilities

​4. Map which PSPs (if any) apply to a namespace

​5. Spot risky capabilities via label/annotation search

​6. Human review guidance

​Additional Reading:

More Info:

Risk Level

Address

Compliance Standards

Triage and Remediation

Remediation

Using kubectl

1. List all pods and surface explicit capabilities

2. Inspect full securityContext for specific namespaces

3. Check for PodSecurityPolicy (or replacement) enforcing dropped capabilities

4. Map which PSPs (if any) apply to a namespace

5. Spot risky capabilities via label/annotation search

6. Human review guidance

Additional Reading: