Container Running as Root User

Why Running as Root Is Dangerous

Many container images default to running as root (UID 0). While container isolation provides some protection, a container escape vulnerability combined with root access could give an attacker root on the host node.

Example Without Security Context

apiVersion: apps/v1
kind: Deployment
metadata:
  name: default-user-app
  labels:
    app: myapp
spec:
  replicas: 2
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
        - name: app
          image: python:3.12
          command: ["python", "-m", "http.server", "8080"]
          resources:
            requests:
              cpu: 100m
              memory: 64Mi
            limits:
              cpu: 200m
              memory: 128Mi

What the Validator Flags

• Warning: No securityContext.runAsNonRoot set at pod level

Enforcing Non-Root Execution

Set runAsNonRoot: true at the pod level to prevent any container from running as root:

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

Fixing Images That Require Root

1. Rebuild the image with a non-root USER directive in the Dockerfile
2. Use an init container with root access to set up file permissions, then run the main container as non-root
3. Use fsGroup to manage file ownership for volumes

Pod Security Standards

Kubernetes Pod Security Standards define three levels:

• Privileged: Unrestricted (not recommended)
• Baseline: Prevents known privilege escalations
• Restricted: Heavily restricted, enforces non-root, drops capabilities

Using the Restricted profile enforces runAsNonRoot: true automatically through admission control.