Description
Running as root can give a compromised application more authority over files and processes. Prefer non-root execution and verify the actual UID and granted privileges.
runAsNonRoot set to false does not itself prove root execution. The user depends on runAsUser, Pod and container settings, and the image default. Container root also does not automatically mean unrestricted host access.
Potential impact
A compromised application may make unnecessary file changes or perform administrative operations inside the container. Dangerous capabilities, host mounts or other isolation weaknesses can increase the impact.
Remediation
- Set runAsNonRoot: true and select a non-root runAsUser supported by the image.
- Check overrides in each container and init container as well as Pod settings, and prepare required file and volume permissions.
- Reduce unnecessary capabilities and host access, and verify that the application works as a non-root user.
Examples
These examples show container settings taking precedence over Pod defaults. Check image and file-permission compatibility with the selected UID.
Before
apiVersion: v1
kind: Pod
metadata:
name: security-context-demo-2
spec:
securityContext:
runAsUser: 1000
runAsNonRoot: false
containers:
- name: sec-ctx-demo-2
image: gcr.io/google-samples/node-hello:1.0
securityContext:
runAsUser: 0
allowPrivilegeEscalation: false
runAsNonRoot: false
Although the Pod default is UID 1000, this container runs as UID 0. allowPrivilegeEscalation: false does not turn an already-root process into a non-root process.
After
apiVersion: v1
kind: Pod
metadata:
name: security-context-demo-2
spec:
securityContext:
runAsUser: 10000
runAsNonRoot: true
containers:
- name: sec-ctx-demo-2
image: gcr.io/google-samples/node-hello:1.0
securityContext:
runAsUser: 10100
allowPrivilegeEscalation: false
runAsNonRoot: true
This runs the container as UID 10100 and prevents root execution. Configure file permissions to allow only the paths the application needs.