A developer wants a basic syscall filter on app Pods without custom profiles. Which seccompProfile setting is appropriate awareness-level hardening?
Select an answer to reveal the explanation.
Short Explanation
RuntimeDefault is the stock "safe syscall playlist" the container runtime already ships. Point seccompProfile at it for baseline filtering without hand-writing profiles. Privileged mode and hostNetwork don't give you that filter for free.
Full Explanation
Seccomp filters system calls. For awareness-level hardening on ordinary city app Pods without authoring custom profiles, set securityContext.seccompProfile.type to RuntimeDefault on the Pod or container. That applies the container runtime’s default syscall allowlist—a stock “safe playlist”—and is the common portable baseline referenced in modern Pod Security guidance. It improves syscall filtering without requiring the developer to maintain a custom localhost profile for every municipal microservice.
privileged: true does not enable the strictest seccomp profile; privileged generally weakens isolation and is incompatible with a hardened posture. hostNetwork: true shares the node network namespace and does not mean the Pod inherits a helpful node seccomp profile for free. Configuring seccomp only via Service selector labels does nothing: Services do not apply seccomp, and Pods honor securityContext.seccompProfile when set—not Service labels.
Exam caveat: RuntimeDefault is not the same as Localhost with a custom profile path; know which type you are setting. Some clusters also annotate older seccomp settings—prefer the securityContext field for current exams. Operational check: after deploy, kubectl get pod -o yaml | grep -A5 seccompProfile and confirm type: RuntimeDefault; ensure privileged is false. If admission policies require restricted hardening, RuntimeDefault is typically part of the expected checklist alongside non-root and dropped capabilities for city workloads.