Learn how to resolve the Kubernetes error container has runAsNonRoot and image has non-numeric user with exact steps and working code examples. Our Kubernetes Support Team is always here to help you.
How to Handle container has runAsNonRoot and image has non-numeric user
Running containers in Kubernetes can sometimes throw unexpected errors, and one common problem developers face is the container has runAsNonRoot and image has non-numeric user message. This occurs when your cluster enforces security policies to prevent containers from running as root, but your Docker image uses a username instead of a numeric user ID. Here’s how to tackle this effectively.
Why This Happens
This error happens because Kubernetes cannot confirm that a named user like appuser is not running as root. Kubernetes relies on numeric UIDs to validate the non-root status. Using a symbolic username (like USER appuser) prevents verification since the mapping of usernames to UIDs exists only inside the container’s /etc/passwd file.
Understanding the Root Cause
When you encounter this error, it usually stems from the Dockerfile or PodSecurityPolicy configuration. In the Kubernetes source code, this situation is handled with the following logic:
case uid == nil && len(username) > 0:
return fmt.Errorf("container has runAsNonRoot and image has non-numeric user (%s), cannot verify user is non-root", username)And in the validation call:
// Verify RunAsNonRoot. Non-root verification only supports numeric user.
if err := verifyRunAsNonRoot(pod, container, uid, username); err != nil {
return nil, cleanupAction, err
}As seen, the core issue is uid == nil. Therefore, the most reliable solution is to assign a numeric UID.
How to Correct It
You can resolve this by setting a numeric UID in your Dockerfile and Kubernetes Pod security context. Here’s how it works in practice:
Add a numeric USER in Dockerfile:
USER 9000:9000Here, 9000 is an arbitrary numeric ID. Make sure the user exists within the container.
Update your Pod securityContext:
For example, if you’re working with Fluentd pods, update the route.yml or pod specification as follows:
fluentd:
## Specifies whether a PodSecurityPolicy should be created
podSecurityPolicy:
create: true
securityContext:
## The group ID of all processes in the statefulset containers. By default this needs to be fluent(999).
fsGroup: 999
runAsUser: 999
...Adjust your route configuration if needed:
Sometimes, the cluster enforces stricter permissions depending on the hostname. For instance:
from:
maximo-lab.domain.com
to:
maximo-lab.subdomain.domain.comBy aligning with the cluster permissions, the non-root enforcement works smoothly.
Key Takeaways
- The error is common when symbolic usernames are used instead of numeric UIDs.
- Kubernetes can only verify non-root status with numeric IDs.
- Adding USER 9000:9000 in Dockerfile and runAsUser: 999 in securityContext resolves the problem.
- Always ensure the user exists in the container and has the right file permissions.
- Adjust your pod or route specifications based on cluster permission requirements.
[If needed, Our team is available 24/7 for additional assistance.]
Conclusion
With these adjustments, your pods will satisfy Kubernetes security policies, and you’ll avoid the container has runAsNonRoot and image has non-numeric user error in future deployments.
