A container with privileged set to true is not meaningfully isolated from the node. The Kubernetes docs say the Privileged policy level lets pods bypass container isolation, for example by using the node's host network. Almost no application workload needs it, and the Baseline Pod Security Standard forbids it.
The settings that remove isolation
The Baseline standard lists what ordinary workloads must not do. Each item below must be unset or false:
- privileged containers
- hostNetwork, which shares the node's network
- hostPID, which shares the node's process namespace
- hostIPC, which shares the node's IPC namespace
Baseline also requires that hostPath volumes are not used, and that host ports are unset or limited to a known list.
Any one of these gives the pod a view of or a route into the node. Combined, they are close to running directly on the host.
hostPath volumes
A hostPath volume mounts part of the node's filesystem into the pod. The RBAC guidance says that being able to create arbitrary persistent volumes can allow hostPath, which gives pods access to the node filesystem. So two routes lead to the same exposure: a pod spec with hostPath, and a PersistentVolume with hostPath. Restrict both, and see Kubernetes RBAC mistakes.
Why teams ask for it
- Monitoring and security agents that read node data.
- Storage drivers and network plugins.
- Docker in Docker builds.
- Debugging.
Alternatives
Builds: use an isolated builder, not a privileged pod. See mounting the Docker socket.
A single missing permission: add the specific capability, not privileged. Capabilities split root into small pieces, and Baseline allows a short list. See drop all capabilities and add back.
Node level agents: run them in a dedicated namespace marked Privileged, on dedicated nodes, kept away from application pods. The RBAC guidance recommends keeping powerful pods apart from untrusted or exposed ones using taints, affinity or anti-affinity, and keeping DaemonSets to the minimum.
Debugging: use short-lived, audited access and remove it afterwards.
Making it stick
Enforce Baseline or Restricted on every application namespace, and keep the list of Privileged namespaces short and reviewed. Do not exempt controller service accounts, since the docs say that would implicitly exempt anyone who can create the matching workload. Rollout steps are in Pod Security admission rollout.
Finding existing privileged pods
List pods across namespaces and filter for the privileged field, host namespace fields and hostPath volumes. Start with namespaces you do not recognize. For each hit, record who owns it and why it exists. Many turn out to be vendor agents that can move to a dedicated namespace, and a few turn out to be leftovers that can simply be deleted.
Quick check
Is privileged the same as running as root?
No. Root is the user inside the container. Privileged changes how much of the host the container can reach.
Can I run a privileged pod in a Restricted namespace?
No. Restricted builds on Baseline, which does not allow privileged containers.
Sources
Last reviewed: 19 October 2026.
