Lesson 0024 · 20 minutes · Cluster Hardening
Remove an unnecessary Secret-read permission
This is an exam-style remediation: an existing workload identity has more access than it needs. Change only the permission rule, preserve the established identity and binding, and prove the boundary.
Timed task: 12 minutes
Apply lab/lesson-24-fixture.yaml. The release-bot ServiceAccount in namespace release is overprivileged.
Create lab/lesson-24-answer.yaml containing a replacement for only the existing Role release-bot-reader. Preserve its name and namespace. After your change, the ServiceAccount must:
- Be able to
get,list, andwatchConfigMaps inrelease. - Have no permission to read Secrets.
- Have no permission to create ConfigMaps.
Do not create another Role, RoleBinding, ClusterRole, or ServiceAccount. The RoleBinding already connects the correct identity to the correct Role.
Verification
kubectl --context kind-cks-lab apply -f .\lab\lesson-24-fixture.yaml
kubectl --context kind-cks-lab apply -f .\lab\lesson-24-answer.yaml
$sa = 'system:serviceaccount:release:release-bot'
kubectl --context kind-cks-lab auth can-i get configmaps --as=$sa -n release
kubectl --context kind-cks-lab auth can-i list configmaps --as=$sa -n release
kubectl --context kind-cks-lab auth can-i watch configmaps --as=$sa -n release
kubectl --context kind-cks-lab auth can-i get secrets --as=$sa -n release
kubectl --context kind-cks-lab auth can-i create configmaps --as=$sa -n releaseExpected results: yes yes yes no no.
Retrieval check
Question
Why is it better to remove the Secret permission from the existing Role than to create a second, narrower Role and binding?
Documentation target
Use the official Kubernetes RBAC reference for rules, bindings, and ServiceAccount subject names.
What to send me
Paste only the replacement Role and the five can-i results. I’ll review it one issue at a time and will not reveal the next correction early.