More Info:
Do not generally permit containers with the potentially dangerous NET_RAW capability.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
-
List current workload security settings (PSPs, PSP replacements, and policies)
Run on: any machine with kubectl access -
Discover pods that currently have NET_RAW capability
Run on: any machine with kubectl accessReview the output and identify which workloads:- explicitly add
NET_RAW, or - fail to drop
NET_RAWby not droppingALL(and not droppingNET_RAWspecifically).
- explicitly add
-
Review pod and namespace security configuration for each affected workload
For each(namespace, pod, container)from step 2:Manually check:securityContext.capabilities.addforNET_RAWsecurityContext.capabilities.dropincludesALLor at leastNET_RAW- Whether any namespace or policy enforces a required drop of
NET_RAW/ALL.
-
Decide if each use of NET_RAW is strictly necessary
For each affected container, consult the owning team and application documentation to determine:- Is raw socket / packet crafting actually required (e.g., low-level networking, certain monitoring agents, specialized load balancers)?
- If yes, can the function be achieved using higher‑level networking APIs or sidecar patterns instead?
- If no, plan to remove
NET_RAWby:- eliminating it from
securityContext.capabilities.add, and/or - adding
NET_RAWorALLtosecurityContext.capabilities.drop.
- eliminating it from
-
Adjust policies/manifests to require dropping NET_RAW (or ALL) where safe
Based on step 4 decisions:- For namespace/workload manifests (Deployment/DaemonSet/Job/etc.), edit source manifests or Helm charts to:
- Remove any
NET_RAWfromsecurityContext.capabilities.add. - Add:
or at minimum:
- Remove any
- For cluster-wide admission controls (PSP if still used, or equivalent OPA/Gatekeeper/Kyverno policies), configure rules that:
- Require
NET_RAWto be dropped, or - Forbid adding
NET_RAW, except for carefully scoped exceptions (namespaces/labels).
- Require
- For namespace/workload manifests (Deployment/DaemonSet/Job/etc.), edit source manifests or Helm charts to:
-
Verify that NET_RAW is no longer generally admitted
After redeploying updated workloads and/or policies, re-run:Confirm:- No general-purpose workloads appear in the list.
- Any remaining entries are explicitly reviewed and documented as justified exceptions.
Using kubectl
Using kubectl
- PSPs missing
requiredDropCapabilitiescompletely. - PSPs with
requiredDropCapabilitiespresent but NOT includingNET_RAWorALL.
requiredDropCapabilities list does not contain NET_RAW or ALL may allow containers with NET_RAW.- At pod-level
securityContext: - Or at container-level:
NET_RAW is a potential concern and requires human review to determine if it is justified.- Any matches show pods or containers declaring
NET_RAWin their capabilities. - Each occurrence should be reviewed to decide whether
NET_RAWis truly required.
- Namespaces labeled with privileged or unrestricted policies (for example,
pod-security.kubernetes.io/enforce=privilegedor similar) can make it easier for workloads to useNET_RAWwithout restriction. - These namespaces require closer review of workloads using the checks above.
Use these commands to collect evidence. Determining whether and where to forbid
NET_RAW (e.g. via PodSecurityPolicy or other admission controls) requires human judgment based on application needs and acceptable risk.Automation
Automation

