Minimize The Admission Of Containers With Capabilities Assigned

# 1) List all namespaces
# Run on: any machine with kubectl access
kubectl get namespaces -o name

# 2) List all pods in a namespace with their securityContext
# Replace <namespace> with the target namespace name
kubectl get pods -n <namespace> -o yaml \
  | sed -n '/containers:/,/^status:/p' \
  | sed -n '/- name:/,/resources:/p'

kubectl get pods -n <namespace> -o jsonpath='{range .items[*]}{.metadata.name}{"\n"}{range .spec.containers[*]}{"  "}{.name}{" -> "}{.securityContext.capabilities}{"\n"}{end}{"\n"}{end}'

# 3) Check for PodSecurityPolicy objects (legacy, if enabled)
kubectl get podsecuritypolicies.policy

# Inspect each PSP for capability rules
kubectl get podsecuritypolicies.policy <psp-name> -o yaml

# 4) Show Pod Security labels on namespaces
kubectl get ns --show-labels | grep 'pod-security.kubernetes.io/'

# 5) Check deployments (and similar controllers) for capabilities in a namespace
kubectl get deploy -n <namespace> -o yaml \
  | sed -n '/containers:/,/strategy:/p'

# Re-run checks to confirm current state
kubectl get pods -n <namespace> -o jsonpath='{range .items[*]}{.metadata.name}{"\n"}{range .spec.containers[*]}{"  "}{.name}{" -> "}{.securityContext.capabilities}{"\n"}{end}{"\n"}{end}'

kubectl get podsecuritypolicies.policy -o yaml
kubectl get ns --show-labels | grep 'pod-security.kubernetes.io/'

#!/usr/bin/env bash
#
# Report pods and (Cluster)PodSecurityPolicies that allow Linux capabilities
# Run on: any machine with kubectl access
# Requires: kubectl, jq
set -euo pipefail

echo "=== 1) Namespaces and pods using container securityContext.capabilities ==="
echo "NOTE: Focus on namespaces that should NOT need extra capabilities."

kubectl get pods --all-namespaces -o json \
  | jq -r '
    .items[]
    | . as $pod
    | (
        ($pod.spec.containers // [])
        + ($pod.spec.initContainers // [])
      )[]
    | select(.securityContext.capabilities != null)
    | (
        $pod.metadata.namespace   as $ns
      | $pod.metadata.name        as $podname
      | .name                     as $cname
      | .securityContext.capabilities.add   // [] as $add
      | .securityContext.capabilities.drop  // [] as $drop
      | [$ns,$podname,$cname,($add|join("|")),($drop|join("|"))]
      | @tsv
    )
  ' \
  | awk 'BEGIN {
           OFS="\t";
           print "NAMESPACE","POD","CONTAINER","CAP_ADD","CAP_DROP"
         }1' \
  | column -t

echo
echo "=== 2) PodSecurityPolicies (if any) and their capability rules ==="
if kubectl api-resources | grep -q '^podsecuritypolicies'; then
  kubectl get podsecuritypolicies.policy -o json \
    | jq -r '
      .items[]
      | .metadata.name as $name
      | .spec.privileged as $priv
      | (.spec.requiredDropCapabilities // []) as $reqDrop
      | (.spec.allowedCapabilities // []) as $allowed
      | (.spec.defaultAddCapabilities // []) as $defaultAdd
      | [$name,
         $priv,
         ($reqDrop|join("|")),
         ($allowed|join("|")),
         ($defaultAdd|join("|"))
        ]
      | @tsv
    ' \
    | awk 'BEGIN {
             OFS="\t";
             print "PSP","PRIVILEGED","REQUIRED_DROP","ALLOWED_CAPS","DEFAULT_ADD_CAPS"
           }1' \
    | column -t
else
  echo "No PodSecurityPolicy API found in the cluster."
fi

echo
echo "=== 3) Namespaces and applied Pod Security admission labels (if any) ==="
echo "Relevant labels: pod-security.kubernetes.io/enforce, audit, warn"
kubectl get ns --show-labels \
  | awk 'NR==1 || /pod-security.kubernetes.io/'

echo
echo "=== INTERPRETING THE OUTPUT ==="
cat <<'EOF'
Section 1 (pods with capabilities):
- A potential problem is indicated when:
  - CAP_ADD column is non-empty, especially for high-privilege caps (e.g. NET_ADMIN, SYS_ADMIN, SYS_PTRACE).
  - CAP_DROP does not include ALL, or is empty, in namespaces where workloads do not need extra capabilities.
- Focus first on:
  - Application namespaces (not kube-system or system add-ons) where CAP_ADD is set.
  - Namespaces that should be “locked down” but have many CAP_ADD entries.

Section 2 (PodSecurityPolicies):
- A potential problem is indicated when:
  - PRIVILEGED is true for PSPs used by regular application namespaces.
  - ALLOWED_CAPS is non-empty or contains ALL.
  - REQUIRED_DROP does not contain ALL for PSPs intended to strictly forbid capabilities.

Section 3 (Pod Security admission labels):
- A potential gap is indicated when:
  - Application namespaces do not have enforce-level labels set to a restrictive level (e.g. enforce=restricted).
  - There is no policy or label mechanism tied to capability restrictions.

Use these reports to decide, per namespace:
- Which workloads can safely drop all capabilities.
- Where a stricter admission policy (e.g. PSP equivalent / Pod Security admission / OPA/Gatekeeper) should be applied to forbid capabilities for pods that do not need them.

There is no fully automated fix: each flagged workload must be reviewed with its owner
to confirm whether capabilities are actually required.
EOF