Detecting Privileged Containers

The Danger of Privileged Containers

A privileged container has almost unrestricted access to the host system. It can access all devices, modify host network settings, and escape container isolation. Running as root (user ID 0) further compounds the risk.

Example with Security Issues

apiVersion: apps/v1
kind: Deployment
metadata:
  name: risky-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: risky
  template:
    metadata:
      labels:
        app: risky
    spec:
      containers:
        - name: app
          image: myapp:1.0
          securityContext:
            privileged: true
            runAsUser: 0

What the Validator Flags

• Error: Container 'app' runs in privileged mode. This is a security risk.
• Warning: Container 'app' explicitly runs as root (runAsUser: 0).
• Warning: No securityContext.runAsNonRoot set at pod level.

Security Context Best Practices

spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    fsGroup: 2000
  containers:
    - name: app
      securityContext:
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
        capabilities:
          drop:
            - ALL

Risk Matrix

Setting	Risk Level	Impact
privileged: true	Critical	Full host access, container escape
runAsUser: 0	High	Root inside container, potential host root
No runAsNonRoot	Medium	Depends on image default user
allowPrivilegeEscalation: true	Medium	Processes can gain more privileges

Most workloads do not need privileged access. If your container needs specific capabilities (e.g., binding to port 80), use capabilities.add instead of privileged mode.