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 GKE
  • 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. List all PodSecurityPolicies (PSPs)
    • Run on: any machine with kubectl access
    If no PSPs are returned, this finding does not apply.
  2. Inspect PSPs for allowedCapabilities usage
    • Run on: any machine with kubectl access
    Note each PSP name where allowedCapabilities appears and what capabilities are listed.
  3. Decide which workloads actually require extra capabilities
    • For each PSP that has allowedCapabilities, identify the namespaces/service accounts using it:
    • Review the deployments/daemonsets/statefulsets in those namespaces to determine which applications truly need specific Linux capabilities and why (e.g., low‑level networking, privileged storage drivers). Document required capabilities per workload.
  4. Tighten or remove allowedCapabilities in PSP manifests
    • For PSPs where no workloads strictly need extra capabilities, plan to remove the field or set it to an empty list.
    • For PSPs where extra capabilities are justified, restrict them to the minimal, documented set required.
    • Edit the PSP manifest(s) (from your Git/IaC or by exporting, editing, and re‑applying):
      • Export (if needed):
      • In each <psp-name>.yaml:
        • Preferable: remove the allowedCapabilities field entirely from .spec.
        • If you must keep it, set it to an empty array:
      • Apply the updated PSP(s):
  5. Verify no PSPs grant added capabilities
    • Run on: any machine with kubectl access
    • Confirm either:
      • allowedCapabilities does not appear at all, or
      • Where it appears, it is set to allowedCapabilities: [].
  6. Monitor for workload impact and adjust if needed
    • Watch for pod failures in affected namespaces:
    • If pods fail due to missing capabilities, reassess and reintroduce only the specific, minimally required capabilities into the relevant PSP, then re‑verify using step 5.
Review guidance:
  • A PSP is problematic for this control if its YAML contains either:
    • allowedCapabilities: with one or more items, for example:
      or
    • allowedCapabilities: null (treated as unrestricted in some versions).
  • A PSP is aligned with this control if:
    • allowedCapabilities field is absent entirely, or
    • Present but set to an empty array, for example:
Use the per‑PSP kubectl get ... -o yaml output to decide, with application owners, whether any non-empty allowedCapabilities are strictly required before planning changes in manifests or admission policy.
Explanation of problematic output:
  • In the “Summary of allowedCapabilities per PodSecurityPolicy” section, any row where the second column is NON-EMPTY indicates a PSP that does not comply with the recommendation.
  • In the “PSPs with NON-EMPTY allowedCapabilities (REVIEW REQUIRED)” section, every listed PSP must be manually reviewed; these are the specific PSPs that allow extra capabilities.
  • For each such PSP, any pods shown under “Pods bound to PSPs with NON-EMPTY allowedCapabilities” are the workloads currently depending on that relaxed policy and should be part of the manual risk/exception review.

Additional Reading: