Kubernetes "container has runAsNonRoot and image will run as root": fix the image or the pod

1. Check which user the image runs as

The user comes from the last USER line of the Dockerfile — or from the base image, if the Dockerfile has none:

docker image inspect -f '{{.Config.User}}' registry.example.com/web:1.4.2

• Empty, root or 0: the image runs as root. Most official base images (node, python, nginx, golang) do, unless you change it.
• A name, like node or app: see section 3 — this is the other variant of the error.
• A number, like 10001 or 1000:1000: fine; the error must come from something else (a runAsUser: 0 in the pod spec).

Without Docker at hand, crane config <image> | jq .config.User or skopeo inspect --config docker://<image> show the same.

2. Fix the image: a numeric non-root user

The cleanest fix is in the Dockerfile — create a user and switch to it, by number:

FROM python:3.13-slim
RUN useradd --system --uid 10001 --no-create-home --shell /usr/sbin/nologin app
WORKDIR /app
COPY --from=build /opt/venv /opt/venv
COPY . .
USER 10001
CMD ["gunicorn", "--bind", "0.0.0.0:8000", "app:app"]

Official images often already have a user you can reuse: node images have node (UID 1000), nginxinc/nginx-unprivileged runs as 101, distroless images have nonroot (65532). The Dockerfile Generator writes multi-stage Dockerfiles that end with a numeric USER for exactly this reason.

3. “image has non-numeric user (node), cannot verify user is non-root”

Error: container has runAsNonRoot and image has non-numeric user (node), cannot verify user is non-root (pod: "web-…", container: web)

The image does run as a normal user — but by name. The kubelet only sees the image config, not the image’s /etc/passwd, so it can’t know whether node is UID 1000 or UID 0. With runAsNonRoot: true it refuses rather than guess. Two fixes, either is enough:

• In the Dockerfile, use the number: USER 1000 instead of USER node.
• In the pod spec, tell Kubernetes the UID, so it doesn’t need to look it up:

spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    runAsGroup: 1000

4. Can’t change the image? Set runAsUser

For a third-party image that runs as root but doesn’t need to, set the user in the pod. Kubernetes then starts the process with that UID, whatever the image says:

spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 10001
    runAsGroup: 10001
    fsGroup: 10001          # mounted volumes become writable for this group
  containers:
    - name: web
      image: registry.example.com/web:1.4.2
      securityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop: ["ALL"]

The pod now starts — but the app may fail next, with Permission denied on a file the image created for root, or bind: permission denied on port 80. Then the image really needs root for something; fix the image (section 2) rather than dropping runAsNonRoot. The Kubernetes Manifest Generator writes this whole security context, which meets the “restricted” Pod Security Standard.

5. Where runAsNonRoot comes from

If you don’t remember setting it, look for it:

kubectl get pod web-7c9d8b6f5d-x2k4q -o jsonpath='{.spec.securityContext}{"\n"}{.spec.containers[*].securityContext}{"\n"}'

It can come from your manifest, from a Helm chart’s default values (many charts set podSecurityContext.runAsNonRoot: true), or from a policy engine like Kyverno or Gatekeeper that adds it automatically. Removing it makes the error go away — and runs your app as root again. Prefer fixing the image.