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 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
Remediation
Manual Steps
Manual Steps
-
Inventory pods and their capabilities
- Run on: any machine with kubectl access
This lists all containers that explicitly add Linux capabilities. -
Classify namespaces and workloads by business/operational need
- Identify security-sensitive or “least privilege” namespaces (e.g.,
prod,payments,defaultfor 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).
- Identify security-sensitive or “least privilege” namespaces (e.g.,
-
Validate necessity of each added capability with workload owners
- For each
(namespace, pod, container)withcapabilities.addfrom 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?
- For each
-
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.addand, where possible, drop all capabilities:
- Apply the updated manifests:
- Confirm the running pods no longer have added capabilities:
- For workloads where capabilities are not strictly needed, update their manifests (Deployments/StatefulSets/DaemonSets/Jobs/CronJobs) to remove
-
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
restrictedor an admission controller / policy engine that forbidscapabilities.addand/or enforcesdrop: ["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.addand ensure it is rejected).
- For namespaces whose workloads do not need any Linux capabilities, implement a guarding admission policy (e.g., Pod Security Standards
-
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.
Using kubectl
Using kubectl
capabilities.add or missing capabilities.drop where your policy expects drop: ["ALL"].drop: ["ALL"] and should be examined.- either require
drop: ["ALL"]for container capabilities, or - otherwise ensure no additional capabilities can be added.
capabilities.add or not dropping all capabilities where your policy expects no capabilities are candidates for redesign or exemption.Automation
Automation

