A city permits API only needs to read ConfigMaps and update its own Deployment inside the permits namespace. A teammate drafts a ClusterRoleBinding to a ClusterRole with those verbs. What change best applies least privilege?
Select an answer to reveal the explanation.
Short Explanation
Think building keys versus master keys. This app only works in one hallway, so a namespace Role is the right key — not a cluster-wide badge. ClusterRoleBindings hand out building-wide power the permits team does not need.
Full Explanation
A city permits API that only needs to read ConfigMaps and update its own Deployment inside the permits namespace should replace a ClusterRoleBinding with a Role and RoleBinding scoped to permits. ClusterRoleBindings attach ClusterRoles cluster-wide, which over-grants when the workload never needs those verbs outside its namespace. Least privilege for municipal microservices favors namespace Roles unless the capability is inherently cluster-scoped.
Keeping the ClusterRoleBinding but removing only the Deployment update verb still leaves ConfigMap access cluster-wide, which remains excessive for this app. Switching the subject to cluster-admin so one binding covers every namespace worsens privilege dramatically. Converting the ClusterRole into a ClusterRoleBinding only fails because bindings reference roles; a binding alone does not invent namespace limits without the correct Role or RoleBinding pairing.
Exam caveat: ClusterRole plus RoleBinding can grant namespaced use of a shared rule set—distinct from ClusterRoleBinding, which is cluster-wide. Operational check: remove the ClusterRoleBinding, create Role and RoleBinding in permits for the app ServiceAccount, verify auth can-i succeeds in permits and fails in another namespace for the same verbs.