← Kubernetes Pod Security Check

Kubernetes pod security: privileged, hostPath, root and how to fix each

A pod spec decides how much of the node each container can touch. Most pod-related incidents are not clever exploits. They are one setting that removed a boundary, such as a privileged container, a mounted Docker socket or a password committed in plain text.

# hands the node to the container
spec:
  hostNetwork: true
  containers:
    - name: app
      image: web:latest
      securityContext:
        privileged: true

# baseline per container
      securityContext:
        allowPrivilegeEscalation: false
        runAsNonRoot: true
        runAsUser: 10001
        readOnlyRootFilesystem: true
        capabilities:
          drop: [ALL]
        seccompProfile:
          type: RuntimeDefault

The fifteen patterns a line scan can find

What is a good baseline securityContext for a Kubernetes container?

Set allowPrivilegeEscalation: false, runAsNonRoot: true with a numeric runAsUser, readOnlyRootFilesystem: true, capabilities drop: [ALL] and seccompProfile type RuntimeDefault. Mount an emptyDir for any path the app must write, and add back only the capability the workload demonstrably needs.

Is a hostPath volume to /var/run/docker.sock safe?

No. The Docker API is root on the node: a pod that can reach it can start another container with the node filesystem mounted. Mounting it read-only does not restrict the API. Use a build tool that does not need the daemon, or a socket proxy that exposes only the required endpoints.

Does the default Kubernetes setup run containers as root?

Often yes. If neither the pod nor the container sets runAsNonRoot or runAsUser, the container runs as whatever user the image declares, which is frequently root. allowPrivilegeEscalation also defaults to true. Setting both explicitly removes the guesswork.

Check your own manifests

Paste your YAML into Kubernetes Pod Security Check to see every finding with its line, resource, container, risk and fix, or run the CLI in your own repository:

python3 check.py --fail-on-risk

That exits with a nonzero status on any medium or high finding, so you can wire it into your own CI. Expect some findings to be deliberate (a node agent may truly need hostPath or a capability); review each one.