Containerized microservices for a 311 intake API should avoid running as root and should use tight filesystem permissions inside the image. Which hardening choice aligns with that goal?
Select an answer to reveal the explanation.
Short Explanation
A container that runs as root with wide-open files is a gift box for anyone who breaks in. Drop privileges, tighten permissions, and keep the host socket out of the app container. Unprivileged users are the default you want for city microservices.
Full Explanation
Container hardening for microservices includes running as unprivileged users and applying restrictive filesystem permissions so compromise of a 311 intake API container does not automatically yield root or writable system paths. Avoiding root and tightening permissions reduces lateral movement and tampering risk on municipal microservice platforms.
Running every container as privileged root with world-writable directories maximizes blast radius. Mounting the host Docker socket read-write into citizen-facing containers effectively offers host control. Disabling user namespaces and granting CAP_SYS_ADMIN to all workloads by default expands dangerous capabilities.
Exam caveat: rootless/non-root, read-only root filesystems, drop capabilities, and no privileged flag are common container hardening themes. Orchestrator securityContext settings implement many of these controls.
Operational check: set securityContext runAsNonRoot, remove unnecessary capabilities, make app directories non-world-writable, scan images for root requirements, and deploy a test pod proving the 311 service still functions. Fail CI if privileged:true appears on citizen-facing workloads.
Scan runtime pods for privileged containers and hostPath/docker.sock mounts in the 311 namespace, paging the platform team when citizen-facing workloads drift from the unprivileged baseline.