Remove capabilities such as NET_RAW unless the application specifically needs them. NET_RAW can support packet crafting and other low-level network behaviour, which increases abuse potential after compromise. In Kubernetes, check container security settings and only permit the exact capabilities required for the workload to operate.
What Linux capabilities control in a Kubernetes container
Kubernetes does not grant a container full root privileges by default, but linux capabilities still matter because they split root into narrower permissions. Dropping unnecessary capabilities reduces what a process can do even if it is compromised. Container Security Guide and Kubernetes Security Guide both reinforce that capability design belongs in the container security and cluster hardening model, not as an afterthought.
NET_RAW is a good example because it enables raw socket use, which can support packet crafting, packet sniffing, and some network probing behaviours. If a workload does not need that level of access, removing it narrows the blast radius of a compromise and reduces the ways an attacker can abuse the pod from inside the cluster. The practical goal is least privilege for the process, not merely running as non-root.
In Kubernetes, the relevant control point is the pod or container security context. That is where you define a capability drop list, then add back only the specific capability a workload genuinely requires. The safest pattern is to start from the default capability set, remove broad network or kernel-adjacent permissions, and verify the workload still functions under realistic traffic and failure conditions. This keeps the policy tied to actual application behaviour instead of assumptions.
How to restrict NET_RAW without breaking the workload
Most teams should treat capability restriction as an allowlist exercise. If a container needs one narrow privilege, add only that capability and do not preserve the rest of the default set. For Kubernetes, that usually means setting the container security context so the pod drops NET_RAW explicitly, then checking whether the application depends on ICMP, custom packet handling, service discovery probes, or other low-level networking features. If it does, document why that exception exists and keep it tightly scoped.
Useful validation is behavioural, not theoretical. After you apply the restriction, test the pod’s startup path, health checks, outbound connectivity, and any network-dependent jobs. If the service only fails when it tries to use functionality that should not be present in the first place, the restriction is working as intended. If the service fails for legitimate reasons, that is a signal to refine the application design or isolate the exception rather than restoring broad capabilities.
Capability control also fits naturally with other container hardening measures such as non-root execution, seccomp, AppArmor or SELinux profiles, and restrictive network policy. Those controls solve different problems, but they reinforce each other. A container that cannot open raw sockets, cannot write to sensitive paths, and cannot reach arbitrary peers is far harder to repurpose after compromise.
Why capability minimisation matters after compromise
Containers are often attacked through the application layer first, then turned into a foothold for discovery, pivoting, or lateral movement. If a compromised process retains NET_RAW, the attacker may gain more useful networking primitives than the application itself legitimately needs. That widens the gap between initial compromise and meaningful containment. NIST SP 800-190 Container Security is the most relevant external reference for understanding why runtime permissions, orchestrator settings, and isolation controls should be minimised together.
Failure mechanism: the pod is deployed with inherited capabilities that were never reviewed against the workload’s actual needs, so an attacker who reaches the container can use those permissions for network manipulation, reconnaissance, or traffic interference. The risk is highest when teams treat the default capability set as harmless because the pod is “not privileged.” In practice, a single unnecessary capability can still be enough to expand post-compromise options.
Impact: the container becomes easier to abuse as a pivot point, and the incident response team has less confidence that the workload was confined to its intended role. Even when the application is not directly handling sensitive data, extra network primitives can help an attacker map the cluster, test adjacent services, or prepare a deeper foothold.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and CSA Cloud Controls Matrix set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Restricting NET_RAW is a least-privilege decision for container permissions. |
| SC-39 — Process Isolation | Container capability limits support process isolation and reduce abuse after compromise. | |
| Recommendation — Drop unnecessary Linux capabilities and keep only the minimum required by the workload. Enforce isolation boundaries so a compromised container cannot gain broader host or cluster power. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | Container capability settings are configuration items that must be controlled and reviewed. |
| Recommendation — Define and review container capability settings as part of controlled secure configuration. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Kubernetes capability drops are part of secure workload configuration hardening. |
| Recommendation — Harden container security contexts and remove default permissions that the workload does not need. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Cloud workload permissions should be constrained to the minimum required access and privilege. |
| Recommendation — Limit workload privileges to the minimum necessary and review exceptions routinely. | ||
Practitioner Guidance
What to verify: Confirm the exact capabilities the workload actually uses before allowing any exception. If the application owner cannot explain why NET_RAW is needed, default to dropping it and test the service without it.
Decision rule: If a capability is required only for debugging or occasional troubleshooting, keep it out of the production container and use a separate break-glass or diagnostic path instead. If it is truly part of the workload’s core function, scope the exception to that one capability and nothing broader.
What good looks like: The pod runs with the minimum capability set, the security context is defined in code or policy, and any requested exception has an owner, justification, and review path. That is a stronger state than simply “running without privileged mode.”
Practitioner takeaway: Capability restriction is most effective when it is treated as workload-specific engineering, not a generic hardening checkbox, because the value comes from proving that the application can operate without unnecessary kernel-adjacent power.
Related resources from NHI Mgmt Group
- Why does CAP_NET_RAW create such a large attack surface in Kubernetes pods?
- Why do exposed JDWP ports create such a serious risk in containers and Kubernetes?
- Why does allowing SYS_ADMIN or privileged containers increase container escape risk in Kubernetes and Linux environments?
- How should security teams restrict Kubernetes service account permissions for EKS workloads that only need to pull containers?