A county clerk portal needs a ServiceAccount that can list Pods only in the permits namespace, not cluster-wide. Which RBAC approach meets least privilege?
Select an answer to reveal the explanation.
Short Explanation
Least privilege here is like giving a desk key for one office, not the whole courthouse master key. A namespace Role plus RoleBinding limits list-pods to permits for that ServiceAccount. Cluster-wide bindings would overshoot what the clerk portal needs.
Full Explanation
For the county clerk portal, least privilege means the ServiceAccount may list Pods only inside the permits namespace—the civic equivalent of a desk key for one records office rather than a courthouse master key. Kubernetes RBAC encodes that boundary with a namespaced Role whose rules include the pods resource and the list verb, plus a RoleBinding in permits that subjects the portal ServiceAccount. Because both the Role and RoleBinding live in that namespace, authorization never expands to other city namespaces even though the same ServiceAccount name might exist elsewhere. A ClusterRole paired with a ClusterRoleBinding grants the listed verbs across every namespace, which is exactly the over-privilege the clerk portal must avoid when it only needs permitting workloads. Relying on cluster-admin while hoping NetworkPolicies hide Pods confuses network isolation with API authorization: NetworkPolicies filter Pod traffic, they do not strip list rights from the API server. Binding the built-in cluster-admin ClusterRole through a RoleBinding in permits still applies that powerful ClusterRole’s ruleset in the binding’s namespace, which typically includes far more than list-pods and is still the wrong privilege model for a narrow portal identity. Exam caveat: remember the Role versus ClusterRole and RoleBinding versus ClusterRoleBinding matrix—namespace confinement comes from the binding type and Role scope, not from wishing NetworkPolicy would act as RBAC. Operational check: after applying the Role and RoleBinding, impersonate or exec as the portal ServiceAccount and confirm kubectl auth can-i list pods -n permits is yes while the same check in another municipal namespace is no; review kubectl get role,rolebinding -n permits to ensure no ClusterRoleBinding was left attached to that account.