City auditors need read-only access to Deployments across every namespace for inventory. Which RBAC design fits?
Select an answer to reveal the explanation.
Short Explanation
Cross-namespace inventory is a building-wide badge, not a single-floor pass. Auditors need a ClusterRole for deployments plus a ClusterRoleBinding so those verbs work in every namespace. A Role stuck in default would miss the rest of the city estate.
Full Explanation
City auditors inventorying Deployments across the entire municipal estate need read verbs that are not trapped in a single namespace. The fitting design is a ClusterRole that allows get, list, and watch on deployments, bound with a ClusterRoleBinding to the auditors’ group (or users). ClusterRoleBindings apply the referenced rules cluster-wide, which is the building-wide badge auditors need for a complete inventory rather than a single-floor pass in default. A Role limited to default only authorizes where that Role exists; repeating it in every namespace is operationally brittle and still is not what a one-shot RoleBinding in default achieves. Issuing node kubelet certificates so auditors scrape a local API cache is the wrong identity and the wrong API surface—kubelet credentials are for node components, not human inventory of Deployments. Storing Deployment YAML in a ConfigMap and granting get on that ConfigMap only provides a static copy, not live API inventory, and does not satisfy continuous audit of actual Deployment objects. Exam caveat: cross-namespace reads of namespaced resources require ClusterRole plus ClusterRoleBinding (or equivalent cluster-scoped authorization), not a lonely namespaced Role. Operational check: bind a test auditor subject, then run kubectl get deploy -A (or auth can-i list deployments --all-namespaces) and confirm success without granting write verbs; kubectl describe clusterrolebinding should show the auditors group and the read-only ClusterRole.