More Info:
Do not generally permit containers with capabilities assigned beyond the default set.Risk Level
MediumAddress
SecurityCompliance 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
Remediation
Manual Steps
Manual Steps
-
List all PodSecurityPolicies (PSPs)
- Run on: any machine with kubectl access
If no PSPs are returned, this finding does not apply. -
Inspect PSPs for
allowedCapabilitiesusage- Run on: any machine with kubectl access
Note each PSP name whereallowedCapabilitiesappears and what capabilities are listed. -
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.
- For each PSP that has
-
Tighten or remove
allowedCapabilitiesin 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
allowedCapabilitiesfield entirely from.spec. - If you must keep it, set it to an empty array:
- Preferable: remove the
- Apply the updated PSP(s):
- Export (if needed):
-
Verify no PSPs grant added capabilities
- Run on: any machine with kubectl access
- Confirm either:
allowedCapabilitiesdoes not appear at all, or- Where it appears, it is set to
allowedCapabilities: [].
-
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.
- Watch for pod failures in affected namespaces:
Using kubectl
Using kubectl
-
A PSP is problematic for this control if its YAML contains either:
allowedCapabilities:with one or more items, for example:orallowedCapabilities: null(treated as unrestricted in some versions).
-
A PSP is aligned with this control if:
allowedCapabilitiesfield is absent entirely, or- Present but set to an empty array, for example:
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.Automation
Automation
- In the “Summary of allowedCapabilities per PodSecurityPolicy” section, any row where the second column is
NON-EMPTYindicates 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.

