User Namespaces

User namespaces provide enhanced security isolation by mapping container user and group IDs to different IDs on the host. This means a process running as root (UID 0) inside a container can be mapped to an unprivileged user on the host, significantly reducing the impact of container escape vulnerabilities.

Prerequisites

User namespaces require SKS nodes with at least kubelet v1.33.1. Ensure your SKS cluster nodes are running a compatible version.

Enabling User Namespaces

SKS clusters support user namespaces out of the box. In order to run a pod with user namespaces enabled, set hostUsers: false in your pod specification:

apiVersion: v1
kind: Pod
metadata:
  name: userns-demo
spec:
  hostUsers: false
  containers:
    - name: demo
      image: alpine
      command: ["sleep", "infinity"]

When hostUsers: false is set, the container runs in a separate user namespace. The root user (UID 0) inside the container is mapped to an unprivileged user ID on the host.

Verifying User Namespace Isolation

To verify that user namespaces are working:

Deploy the pod:
```
kubectl apply -f userns-demo.yaml
```

Check the user ID inside the container:

# kubectl exec userns-demo -- id
# [output]
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video)

Check the mapped user ID on the host by inspecting the container process:
```
# kubectl exec userns-demo -- cat /proc/1/uid_map
# [output]
         0 1317404672      65536
```
The output shows the UID mapping. The first column is the UID inside the container. The second column is the UID from the host perspective, and the third column is the range length.
In the example above, the container is running as root (UID 0), but it maps to UID 1317404672 on the host, indicating that user namespace isolation is active.

Security Benefits

User namespaces provide some security advantages:

Reduced privilege escalation risk since even if a container escape occurs, the attacker gains access to the host as an unprivileged user.
File permission isolation: Host files owned by root remain protected since the container’s root user maps to a different unprivileged UID on the host.
Capability limitations: Capabilities like CAP_SYS_ADMIN are limited to the pod’s user namespace only, not the host.
Pod-to-pod isolation: Each pod gets non-overlapping UID/GID mappings, so escaped containers from different pods run as different unprivileged users on the host.

Pod Security Standards

When using user namespaces, pods running as root inside the container do not violate runAsNonRoot constraints in Pod Security Standards. This is because root inside the container (UID 0) maps to an unprivileged user on the host.

Limitations

Volume file ownership: Files on volumes with UIDs or GIDs outside the mapped 0-65535 range appear as overflow ID (65534) and cannot be modified.