Description
A container’s numeric UID can overlap with another user on the host or a shared volume, potentially allowing unintended file access. The effect depends on user-namespace mappings, accessible mounts and file permissions. A low UID alone does not grant host privileges.
Allocate dedicated non-root UIDs and use them consistently in images and manifests. Raising the number alone does not guarantee isolation.
Potential impact
If ownership UIDs overlap on accessible files, the container may read or change another user’s files. An unplanned UID change can also prevent access to required files and disrupt startup or data processing.
Remediation
- Set runAsUser to an allocated non-root UID and review both Pod defaults and container overrides.
- Align runAsGroup, volume ownership and file permissions with actual UID mappings, and remove unnecessary host mounts.
- Verify that required file access and application operation continue to work while access to other users’ files is denied.
Examples
These examples compare UID assignments. The image must support the chosen UID; prepare required file and volume permissions separately.
Before
apiVersion: v1
kind: Pod
metadata:
name: security-context-demo-2
spec:
securityContext:
runAsUser: 1000
containers:
- name: sec-ctx-demo-2
image: gcr.io/google-samples/node-hello:1.0
securityContext:
runAsUser: 2000
allowPrivilegeEscalation: false
The container overrides the Pod’s UID 1000 and runs as UID 2000. Check for overlaps with other users on its actual mounts.
After
apiVersion: v1
kind: Pod
metadata:
name: security-context-demo-2
spec:
securityContext:
runAsUser: 10000
containers:
- name: sec-ctx-demo-2
image: gcr.io/google-samples/node-hello:1.0
securityContext:
runAsUser: 10100
allowPrivilegeEscalation: false
This selects UID 10100 for the container. A value above 10000 is not itself a safety guarantee; verify the actual allocation and file permissions.