A privileged container is allowed access to host resources normally blocked from containers, including host devices. In Kubernetes, the `privileged` setting in a container’s security context controls this access. Some orchestration components may need host access, but ordinary workloads should not receive it by default. section 13.3.2 section 13.4
Privilege and user identity are separate controls. Running as root inside a nonprivileged container does not by itself grant root access to the worker node. Running as root with `privileged: true`, however, can let a process change host settings or extract host data. A privileged container running as a nonroot user remains limited by that user’s host permissions. section 13.6 section 13.4
Table 13.3 Root and privileged container permissions (view table figure)
| Limited; only permissions that have been granted to the same user on the host system |
Compare host permissions across the four combinations of root or nonroot execution and privileged mode. section 13.6
Testing a host-level change
A root container without privileged mode cannot change a host kernel setting. Enabling privileged mode for that root container permits the change. Switching the privileged container to user 1000 causes the attempted kernel change to be denied again. The result depends on both controls, not either one alone. section 13.6.2
Limit which Pods may run privileged, and define the permitted container user as a separate policy decision. Anthos Config Management includes a Gatekeeper constraint template for denying privileged containers; a `K8sPSPPrivilegedContainer` constraint matched against Pods also checks Pods created through Deployments. Test the constraint before broad enforcement: system namespaces can contain privileged Pods, and an enforced rule may affect their operation. Admission checks apply to newly admitted objects, not existing Pods, although existing violations can be reported. section 13.6.2 section 13.4.1
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPPrivilegedContainer
metadata:
name: psp-privileged-container
spec:
enforcementAction: dryrun
match:
kinds:
- apiGroups: [""]
kinds: ["Pod"]
The sample constraint matches Pods and uses `enforcementAction: dryrun` to identify privileged-container violations before enforcing a denial. section 13.4.1
