Entra sign-in works on the harbor AKS cluster, but every authenticated user is still effectively cluster-admin. What should the security engineer enable for authorization?
Select an answer to reveal the explanation.
Short Explanation
Entra tells AKS who you are; Azure RBAC for Kubernetes decides what you can do. Flip that authorization switch and hand out Reader/Writer/Admin roles—not a blanket cluster-admin for every badge.
Full Explanation
Azure RBAC for Kubernetes authorization maps Entra identities to Kubernetes permissions using built-in roles such as Azure Kubernetes Service RBAC Reader, Writer, Admin, or Cluster Admin at cluster or namespace scope. After Entra sign-in works but every user is still effectively cluster-admin, enabling that authorization mode and assigning least-privilege roles is the fix for the harbor AKS cluster.
Distributing full cluster-admin RoleBinding YAML to every namespace fails by widening privilege and fighting the Azure RBAC for Kubernetes model. Disabling Entra integration to return to a shared admin kubeconfig reverses authentication progress. Assigning only Azure Reader on the AKS Azure resource assumes Kubernetes API authorization is unchanged—and that is the mistake: Azure resource Reader does not automatically become Kubernetes RBAC least privilege inside the API server.
Exam caveat: “Azure RBAC on the AKS resource” and “Azure RBAC for Kubernetes authorization” are different switches—enable the Kubernetes authorization integration explicitly. Operational check: assign Writer at one namespace for a test user, confirm they cannot mutate other namespaces or cluster-scoped objects, and confirm Cluster Admin is reserved for break-glass only.