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.

Exam reflex: before creating new RBAC objects, inspect the existing Role and RoleBinding. Often the smallest safe fix is simply to narrow one Role rule.

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:

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 release

Expected 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.