Loading post…
Red HatNandan HegdeProblem & solution
Why your non-root container dropped its capabilities (and how to fix it)
Summary
A platform engineer traces why a non-root OpenShift container configured with CAP_NET_RAW still fails ping with Operation not permitted. The root cause is that SCC is only an admission-time gate that does not enforce runtime privileges. CRI-O translates the PodSpec into an OCI spec with the capability in the Bounding, Effective, and Permitted sets but deliberately omits ambient capabilities. During the runtime’s UID transition from root to the target non-root user, the kernel clears both Permitted and Effective sets, leaving an empty CapEff. The only mechanism that survives a UID transition for non-root processes is ambient capabilities, which CRI-O intentionally avoids to preserve the Kubernetes assumption that switching to a non-root user drops capabilities. To resolve this, file capabilities can be applied directly to the binary via setcap, avoiding the need for ambient capabilities.
Context
A platform engineer running Red Hat OpenShift faces an issue where a non-root sidecar container that requires CAP_NET_RAW for ICMP ping health checks fails with Operation not permitted, even though the SCC allows it and the PodSpec requests it. The engineer traces the problem through the SCC admission, CRI-O’s capability computation, and the kernel’s UID transition logic.
Approach / What changed
The approach explains the security pipeline from SCC admission through CRI-O’s capability computation to the Linux kernel’s UID transition rules. It describes the gap: SCC is an admission-time gate only, and CRI-O deliberately omits ambient capabilities for non-root containers. To fix the issue, file capabilities (setcap) can be applied to the binary during image build.
Takeaways
SCC is purely an admission-time gate; it does not enforce runtime privileges. After admission, SCC has no communication with CRI-O or the kernel.
CRI-O intentionally omits ambient capabilities for non-root containers to preserve the Kubernetes assumption that runAsNonRoot drops capabilities.
File capabilities via setcap (e.g., cap_net_raw=+ep on the binary) survive UID transitions because the kernel promotes file-level capability bits into Permitted and Effective sets at exec time.
FAQ
What are the tradeoffs of using privileged mode?
Privileged mode populates all five capability sets including Ambient, and disables SELinux, AppArmor, and seccomp. However, it bypasses the entire add/drop logic in CRI-O and grants every capability unconditionally, making it a severe over-grant for a need that only requires one specific capability like CAP_NET_RAW.
Source and freshness
- Source
- developers.redhat.com
- Published
- Added to Yomu
Summaries are generated from the original by a language model. Check the original before relying on it.
Keep reading
Related reading
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
The best engineering reads, once a week
One useful email. Unsubscribe anytime.