Lesson 0005 · 25 minutes · Minimize Microservice Vulnerabilities

Enforce a restricted workload boundary

A hardened Pod is useful; preventing the next insecure Pod is better. This CKS-style task combines namespace labels, admission behavior, and a compliant workload.

Exam reflex: first identify the enforcement scope. Pod Security Admission is configured with labels on the Namespace, not annotations on an individual Pod.

Timed task: 15 minutes

In namespace cks-pss, enforce the restricted Pod Security Standard for the Kubernetes version running in the cluster. Then make the existing orders Pod compliant and running. Create your answer as lab/pod-security-standards-answer.yaml.

Start with kubectl --context kind-cks-lab apply -f .\lab\pod-security-standards-starter.yaml. Your answer must add the required Namespace labels and preserve the Pod name, namespace, image, command, and label.

Proof, not assumption

kubectl --context kind-cks-lab apply -f .\lab\pod-security-standards-answer.yaml
kubectl --context kind-cks-lab -n cks-pss wait --for=condition=Ready pod/orders --timeout=60s
kubectl --context kind-cks-lab -n cks-pss get pod orders -o jsonpath='{.spec.securityContext.seccompProfile.type}{"\n"}{.spec.containers[0].securityContext}'
kubectl --context kind-cks-lab -n cks-pss run root-test --image=busybox:1.37 --restart=Never -- sh -c 'sleep 60'

The final command should be rejected by admission. Remove the failed test Pod if one was created.

Tricky retrieval check

Question

A Pod has spec.securityContext.runAsNonRoot: true, but its only container sets securityContext.runAsUser: 0. In a namespace enforcing restricted, what should you expect?

Documentation target

Use the official Pod Security Standards reference. Look up the exact Namespace label keys and restricted requirements rather than relying on memory.

What to send me

Paste your answer YAML plus the rejection message from root-test. I’ll check both the policy scope and whether your workload satisfies it.