Lesson 0033 · 25 minutes · Minimize Microservice Vulnerabilities

Place hardening controls at the correct scope

A correct control at the wrong YAML level is still an invalid solution. Harden both containers while preserving the sidecar's one required writable path.

Timed task: 15 minutes

Read lab/lesson-33-fixture.yaml. Create lab/lesson-33-answer.yaml from scratch. Preserve the namespace, Deployment name, replica count, selector, labels, container names, images, commands, and port.

Your completed Deployment must:

Do not duplicate Pod-wide fields under each container, mount the writable volume into api, add capabilities, or change either image.

Placement reflex: identity and Pod-wide syscall policy belong under template.spec.securityContext. Privilege escalation, capabilities, and root-filesystem mutability belong under each entry in template.spec.containers.

Verification

kubectl apply --dry-run=client -f .\lab\lesson-33-answer.yaml
kubectl apply -f .\lab\lesson-33-answer.yaml
kubectl -n context-lab rollout status deployment/report-api --timeout=90s
kubectl -n context-lab exec deploy/report-api -c log-exporter -- test -f /var/cache/exporter/events.log
kubectl -n context-lab exec deploy/report-api -c api -- sh -c 'touch /root/blocked'

Expected: schema validation passes, the rollout completes, the sidecar writes its event file, and the API container cannot write to its root filesystem.

Retrieval check

Question

Where does readOnlyRootFilesystem belong?

Documentation target

Use the official Kubernetes security context documentation after your first attempt. Use kubectl explain deployment.spec.template.spec.securityContext and kubectl explain deployment.spec.template.spec.containers.securityContext to confirm scope.

What to send me

Save the YAML, then say check. I will list all issues and help you correct only one per round. Ask me a follow-up question whenever a field's scope is unclear.