A public-facing civic web Pod must not run as UID 0. Which securityContext setting best enforces that requirement?
Select an answer to reveal the explanation.
Short Explanation
runAsNonRoot is the bouncer that refuses a root-only ID at the door. Flip it to true and the kubelet won't start a container that would run as UID 0. Privileged mode, Services, and hostPID don't enforce non-root.
Full Explanation
City policy for a public-facing civic web Pod should refuse to run as UID 0. The securityContext field runAsNonRoot: true (on the container or as a Pod-level default) instructs the kubelet to reject starting a container whose effective user would be root. That is the direct enforcement knob for “must not run as root.” Pair it with an image that already declares a non-root USER, or set runAsUser to a non-zero UID, so the container can start successfully under the non-root rule rather than crash-looping because it still tries to be UID 0.
Setting privileged: true does the opposite of hardening: it grants near-host capabilities and does not enforce non-root identity; “drop root after startup” is not a substitute for runAsNonRoot admission by the kubelet. A ClusterIP Service only publishes an in-cluster virtual IP and ports; Service objects never force container UIDs. hostPID: true shares the node’s PID namespace, weakening isolation, and it does not inherit a mythical “node non-root default” that makes the app process non-root.
Exam caveat: runAsNonRoot prevents root; it does not by itself choose which non-root UID is used—combine it with runAsUser/runAsGroup or a correct image USER. Operational check: after applying the Deployment, kubectl get pod -o jsonpath='{.spec.containers[*].securityContext}' (and Pod-level securityContext) and confirm runAsNonRoot is true; exec or inspect the process list to verify the civic web process is not UID 0; attempt a misconfigured image that only runs as root and confirm the Pod fails admission/start rather than silently running privileged as root.