Root and NET_ADMIN under Pod Security Standards

WHAT THIS TESTS This joins two layers: configuring the pod's privileges via securityContext, and understanding that namespace-level Pod Security admission can block such a pod regardless of how it is written.

A GOOD ANSWER COVERS In the container's securityContext you set runAsUser: 0 to run as root, or rely on the image default, and add the capability with capabilities.add listing NET_ADMIN, which permits network configuration like managing interfaces and routes. You would not set privileged: true since that grants far more than needed. The second half is admission control. Pod Security Standards come in three profiles enforced per namespace via labels. The Restricted profile is the strictest: it requires runAsNonRoot and forbids adding any capabilities beyond a tiny default set, so it rejects this pod outright. The Baseline profile is more permissive but still disallows adding NET_ADMIN and most capabilities. Only the Privileged profile, which is essentially unenforced, will admit a root pod with NET_ADMIN. So the namespace must carry pod-security.kubernetes.io/enforce set to privileged, or the pod is rejected at creation.

COMMON WRONG ANSWERS Thinking the securityContext is sufficient on its own ignores admission. Reaching for privileged: true when only NET_ADMIN is needed over-grants. Confusing which capabilities Baseline allows; Baseline blocks NET_ADMIN.

LIKELY FOLLOW-UPS The difference between enforce, audit, and warn modes. Why running as root is discouraged. How to isolate this legacy pod in its own privileged namespace.

ONE CONCRETE EXAMPLE A VPN sidecar needs NET_ADMIN to manage tunnels. You set runAsUser 0 and capabilities add NET_ADMIN, then place it in a namespace labeled enforce=privileged. In a Restricted namespace the API server rejects it before scheduling.