User Namespaces in Kubernetes are designed to improve pod isolation by mapping container users to non-root UIDs on the host. While they offer a promising sandboxing mechanism, their security implications are nuanced. For offensive security practitioners, understanding how user namespaces work opens doors to assess potential privilege escalation, misconfigurations, and runtime escape attempts in hardened clusters.
What Are Kubernetes User Namespaces?
In traditional Kubernetes setups, containers often run as root (UID 0), which also maps to root on the host unless otherwise restricted (e.g., with seccomp, AppArmor, or dropping capabilities). With User Namespaces, UID 0 inside the container can be mapped to a non-root UID (e.g., 100000) on the host, drastically reducing the risk of container breakout.
Core Concept:
| Container UID | Mapped Host UID |
|---|---|
| 0 | 100000 |
| 1 | 100001 |
| 1000 | 101000 |
This mapping isolates privilege levels, ensuring that root inside the container ≠ root on the host.
Offensive Security Perspective: Attack Surface & Evasion Tactics
Despite the promise of tighter isolation, user namespaces introduce complexity that can be exploited or abused if not configured properly. Let’s analyze common offensive scenarios.
1. Privilege Escalation via Misconfigured Mappings
If the UID/GID mappings are too broad, or improperly configured (e.g., overlapping ranges), an attacker could potentially:
- Access sensitive host resources via mapped UIDs.
- Use remapped file permissions to exploit volume mounts (e.g., hostPath or PVCs).
- Abuse misaligned subuid/subgid ranges to escalate outside the intended sandbox.
Example Attack:
bashCopyEdit# Container UID 0 maps to Host UID 100000
# But /data is mounted with files owned by Host UID 100000
cat /data/secrets.txt
Result: UID 0 inside the container has effective access to host-owned files, violating isolation.
2. Kernel Exploits Inside Namespaces
Even with UID remapping, the container shares the kernel. User namespaces do not prevent kernel-level exploits such as:
- DirtyPipe (CVE-2022-0847)
- Dirty COW (CVE-2016-5195)
- StackRot (CVE-2023-3269)
Red Team Tactic:
If CAP_SYS_ADMIN is not dropped, or seccomp filters are lax, you can test kernel exploits inside user namespaces with minimal detection due to reduced apparent privileges.
# Run DirtyPipe exploit inside a user-namespaced container
./dirtypipe /etc/passwd "root::0:0:root:/root:/bin/bash\n"
3. Anti-Forensics & Evasion with Mapped UIDs
User namespaces make detection more complex from a blue team’s perspective:
- Logs might show actions from UID 100000+ on the host instead of UID 0.
- Traditional forensic tooling might miss attribution of malicious activity if unaware of the mapping.
Example:
bashCopyEdit# From container: creates a backdoor as UID 0
echo "malicious_user:x:0:0::/root:/bin/bash" >> /etc/passwd
On host, this action appears as being made by UID 100000 — not obviously suspicious unless correlated with namespace mappings.
4. Side-channel and Shared Resource Attacks
Even with user namespaces, shared resources can become attack vectors:
- cgroups, /proc, and /sys access
- Spectre/Meltdown-style attacks
- CPU time, memory pressure side channels
Tactic:
Use PID or mount namespace escape primitives combined with user namespace to test access to host-level interfaces. For example:
lsns -t user,pidIf misconfigured, you may be able to observe or interfere with host-level processes.
What Doesn’t Work (Defense Successes)
User namespaces offer strong mitigations against:
| Threat | Mitigated by User Namespaces |
|---|---|
| Direct host root access | ✅ |
| Access to host UID 0 files | ✅ |
| CAP_SYS_ADMIN container use | ✅ (if dropped) |
| AppArmor/SELinux bypass | ✅ (if enforced properly) |
However, they do not protect against:
- Kernel-level vulnerabilities
- Volume mount misconfigurations
- Lax seccomp/bpf policies
- Insufficient container runtime restrictions (e.g., allowing
--privileged)
Offensive Testing Setup
You can simulate a user namespace-enabled cluster using:
yamlCopyEditapiVersion: v1
kind: Pod
metadata:
name: userns-test
spec:
securityContext:
runAsUser: 0
runAsGroup: 0
seccompProfile:
type: RuntimeDefault
runtimeClassName: "userns"
containers:
- name: test
image: alpine
command: ["/bin/sh", "-c", "id && sleep 3600"]
Check the UID mappings inside the container:
cat /proc/self/uid_mapUse host PID or mount checks to assess boundary enforcement.
How to Defend Against Offense
| Defense Layer | Best Practices |
|---|---|
| UID/GID Mapping | Use minimal, non-overlapping ranges (subuid, subgid) |
| Capabilities | Drop all except required ones (especially CAP_SYS_ADMIN) |
| Seccomp | Enforce strict syscall profiles (RuntimeDefault, Custom) |
| Volume Management | Avoid hostPath; use projected volumes or CSI |
| RuntimeClass Enforcement | Use PodSecurityAdmission or Kyverno/Gatekeeper to enforce runtimeClassName |
Conclusion
While User Namespaces are a powerful isolation primitive in Kubernetes, they’re not a silver bullet. Offensive security testing shows that, when misconfigured or poorly integrated with other controls, user namespaces can be subverted or bypassed. A layered defense including syscall filtering, strict capability drops, and forensic visibility tooling — is essential.
If you’re building hardened Kubernetes platforms, test user namespaces like an attacker. Simulate kernel exploits, map UID collisions, and validate how well the telemetry captures identity mappings.
