Lesson 0004 · 25 minutes

Harden a workload without breaking it

You already know how to write YAML. This drill trains the security-engineering question: which process-level privileges does this workload actually need?

The hardening controls

• runAsNonRoot: true and runAsUser: 1000: prevents the process from running as UID 0.
• allowPrivilegeEscalation: false: blocks gaining more privilege through mechanisms such as setuid binaries.
• capabilities.drop: ["ALL"]: removes Linux capabilities unless one is explicitly justified.
• readOnlyRootFilesystem: true: prevents writes to the image filesystem.
• seccompProfile.type: RuntimeDefault: applies the container runtime’s default syscall filter.

Use the official Linux kernel security constraints and SecurityContext task guide if you need syntax or a deeper explanation.

Timed task: 15 minutes

The existing inventory pod in namespace cks-workload is intentionally insecure. Create lab/workload-hardening-answer.yaml that preserves the pod name, namespace, image, command, and label while adding every control from the list above.

1. Inspect the current manifest: kubectl --context kind-cks-lab -n cks-workload get pod inventory -o yaml.
2. Write your replacement manifest from memory. The fast way to replace a Pod is kubectl --context kind-cks-lab replace --force -f .\lab\workload-hardening-answer.yaml.
3. Wait for it: kubectl --context kind-cks-lab -n cks-workload wait --for=condition=Ready pod/inventory --timeout=60s.
4. Verify identity: kubectl --context kind-cks-lab -n cks-workload exec inventory -- id. It must show a non-zero UID.

Retrieval check

What to send me

Paste your YAML plus the output of id. I’ll verify the security context and show you one exam-speed inspection command.