Workloads with a container running in privileged mode

Privileged mode switches off container isolation

The Pod API reference defines privileged in one line: processes in privileged containers are essentially equivalent to root on the host. The field defaults to false. The Pod Security Standards say privileged pods disable most security mechanisms, and list the setting under the Baseline profile, the minimum policy meant to block known privilege escalations. Only the fully permissive Privileged profile allows it.

Whoever compromises a privileged container has, for most purposes, compromised the node and every other pod scheduled there, because the usual container boundaries no longer hold.

Listing privileged containers

kubectl get deployments,statefulsets,daemonsets -A -o json | jq -r '
  .items[] | .kind as $k | .metadata as $m
  | (.spec.template.spec.containers + (.spec.template.spec.initContainers // []))[]
  | select(.securityContext.privileged == true)
  | "\($k) \($m.namespace)/\($m.name) \(.name)"'

Any explicit true is enough

ZopNight checks the security settings recorded for every container and init container in Deployments, StatefulSets and DaemonSets. A container counts only when privileged is explicitly true; an unset field is treated as false, matching the Kubernetes default. The finding names each privileged container in the workload and is rated critical.

No namespace exception in the rule

Unlike the host-network check, the rule itself excludes no namespaces. ZopNight does not collect workloads in kube-system, kube-public or kube-node-lease (or GKE’s own system namespaces), so system components there never appear; privileged agents installed in other namespaces do. Review those and accept the ones you rely on deliberately. A workload with no containers recorded, or with no privileged container, is silent. Ephemeral containers are not evaluated. Related findings are Container running as root and Container with host network.

Critical exposure, no saving

The finding carries no cost estimate. What is at stake is the node: a privileged container is one exploit away from full control of the machine it runs on.

Removing privileged mode

1. Find out why it was set. Often the container needs one specific kernel capability, not all of them.
2. Remove securityContext.privileged: true.
3. Grant only the required capabilities with securityContext.capabilities.add, for example NET_ADMIN, and keep the rest dropped.
4. Enforce at least Baseline on application namespaces with the pod-security.kubernetes.io/enforce: baseline label, starting in warn mode to see what would break.