Skip to main content

More Info:

Do not generally permit containers with capabilities assigned beyond the default set.

Risk Level

Medium

Address

Security

Compliance Standards

  • APRA CPS 234 (Australia)
  • BSI C5 (Germany)
  • Brazil LGPD
  • CCPA / CPRA (California)
  • CIS Critical Security Controls v8
  • CIS EKS
  • CMMC 2.0
  • CSA Cloud Controls Matrix v4
  • DPDPA
  • Digital Operational Resilience Act (EU)
  • Essential 8
  • ISO/IEC 27017
  • ISO/IEC 27018
  • ISO/IEC 27701
  • KSA PDPL
  • MAS Technology Risk Management (Singapore)
  • MITRE ATT&CK (Cloud)
  • NIS2 Directive
  • NIST SP 800-171
  • NYDFS 23 NYCRR 500
  • SWIFT Customer Security Controls Framework
  • Sarbanes-Oxley IT General Controls
  • UK NCSC Cyber Assessment Framework

Triage and Remediation

Remediation

Manual Steps

  1. Inventory pods and their capabilities
    • Run on: any machine with kubectl access
    This lists all containers that explicitly add Linux capabilities.
  2. Classify namespaces and workloads by business/operational need
    • Identify security-sensitive or “least privilege” namespaces (e.g., prod, payments, default for shared apps).
    • For each namespace found in step 1, list workloads and owners:
    • Map each workload to an application/team and document whether it truly requires added capabilities (e.g., NET_ADMIN, SYS_ADMIN, DAC_OVERRIDE).
  3. Validate necessity of each added capability with workload owners
    • For each (namespace, pod, container) with capabilities.add from step 1:
      • Retrieve the full pod spec and security context:
      • Review with the application owner:
        • What specific feature requires each capability?
        • Can the feature be implemented using standard permissions (RBAC, read-only FS, non-root UID) instead of Linux capabilities?
        • Can the capability be replaced with a smaller set or removed entirely?
  4. Harden pod specs by dropping unnecessary capabilities
    • For workloads where capabilities are not strictly needed, update their manifests (Deployments/StatefulSets/DaemonSets/Jobs/CronJobs) to remove .securityContext.capabilities.add and, where possible, drop all capabilities:
    • Apply the updated manifests:
    • Confirm the running pods no longer have added capabilities:
  5. Enforce “no extra capabilities” at the namespace level where appropriate
    • For namespaces whose workloads do not need any Linux capabilities, implement a guarding admission policy (e.g., Pod Security Standards restricted or an admission controller / policy engine that forbids capabilities.add and/or enforces drop: ["ALL"]).
    • Example (if using Pod Security Admission labels):
    • Then verify new pods in that namespace cannot be created with added capabilities (attempt a test pod with capabilities.add and ensure it is rejected).
  6. Re-audit and document residual exceptions
    • Re-run the capability inventory to confirm reduction:
    • For any remaining containers with added capabilities:
      • Ensure there is documented justification, approval, and a review date.
      • Consider adding dedicated “high-privilege” namespaces for them and applying stricter monitoring/alerting on those workloads.
Problem indication: Containers or initContainers showing capabilities.add or missing capabilities.drop where your policy expects drop: ["ALL"].
Problem indication: Any line returned here is a workload explicitly adding Linux capabilities and must be reviewed for necessity.
Problem indication: In namespaces where you intend workloads to run without capabilities, any container listed here is not configured to drop: ["ALL"] and should be examined.
Problem indication: For namespaces where no capabilities should be allowed, corresponding PodSecurityPolicies should:
  • either require drop: ["ALL"] for container capabilities, or
  • otherwise ensure no additional capabilities can be added.
If no such PSP (or equivalent admission policy) exists for those namespaces, admission is not minimized as recommended.
Problem indication: In that namespace, containers showing capabilities.add or not dropping all capabilities where your policy expects no capabilities are candidates for redesign or exemption.

Additional Reading: