Lesson 0007 · 20 minutes · Minimize Microservice Vulnerabilities

Remove API credentials a workload does not need

Every automatically mounted ServiceAccount token is a potential credential exposed through a container compromise. Disable it when the workload does not call the Kubernetes API.

Exam reflex: distinguish identity from credential mounting. A Pod can name a ServiceAccount for policy clarity while still opting out of its token volume.

Timed task: 12 minutes

The checkout Pod runs in the checkout namespace and does not need to call the Kubernetes API. Apply lab/serviceaccount-token-starter.yaml, then create lab/serviceaccount-token-answer.yaml that preserves its name, namespace, label, image, command, and serviceAccountName while preventing the token from being mounted into this Pod.

Use the smallest-scoped native control: make the change at the Pod specification, rather than changing the ServiceAccount globally.

Proof, not assumption

kubectl --context kind-cks-lab apply -f .\lab\serviceaccount-token-answer.yaml
kubectl --context kind-cks-lab -n checkout wait --for=condition=Ready pod/checkout --timeout=60s
kubectl --context kind-cks-lab -n checkout exec checkout -- sh -c 'test ! -e /var/run/secrets/kubernetes.io/serviceaccount/token'
kubectl --context kind-cks-lab -n checkout get pod checkout -o jsonpath='{.spec.automountServiceAccountToken}{"\n"}'

The token-path check must return success and the final command must print false.

Retrieval check

Question

Where should you set the control when only one Pod must not receive a ServiceAccount token, while other Pods using the same ServiceAccount might still need one?

On that Pod’s spec.On the Namespace.On the API server.

Documentation target

Use the official Configure Service Accounts for Pods guide to confirm the precedence of Pod and ServiceAccount token-mount settings.

What to send me

Paste your answer YAML and the output of both proof commands. I’ll check the scope and the runtime credential boundary.