Role-Based Access Control should be used on Kubernetes Services

What does the recommendation "Role-Based Access Control should be used on Kubernetes Services" check?

Audits each AKS cluster for the 'enableRBAC' property and flags any cluster where native Kubernetes role-based access control is switched off, so authorisation falls back to a flat model where any authenticated principal can act cluster-wide. It looks only at whether Kubernetes RBAC is enabled on the cluster object. It does not inspect the actual Role and RoleBinding objects inside the cluster, does not check Azure RBAC for Kubernetes authorisation (a separate '--enable-azure-rbac' feature), and does not evaluate whether your bindings follow least privilege.

Why does "Role-Based Access Control should be used on Kubernetes Services" matter?

Without Kubernetes RBAC, the API server cannot scope what a service account, user or token may do, so a single leaked kubeconfig or compromised pod can read every secret, mutate any workload and pivot across namespaces. That turns a contained incident into a full cluster takeover, and for shared or multi-tenant clusters it removes the boundary that keeps one team's workloads from reaching another's data. The blast radius is concrete: every mounted service-account token becomes a master key, so an SSRF or RCE in one container can drain the whole cluster's secrets and impersonate the control plane. Regulators and auditors treat a cluster with no authorisation model as an unmitigated finding, which can block a release or a compliance attestation. Enabling RBAC restores the principle of least privilege at the authorisation layer, which is exactly what MCSB PA-7 requires.

How do I fix "Role-Based Access Control should be used on Kubernetes Services"?

1. Native Kubernetes RBAC ('enableRBAC') is fixed at cluster creation and cannot be toggled on an existing cluster, so create a replacement: 'az aks create --resource-group <rg> --name <cluster>' enables RBAC by default (the old '--enable-rbac' flag is deprecated because it is now on unless you explicitly pass '--disable-rbac').
2. Migrate workloads to the RBAC-enabled cluster, then for fine-grained control add Azure RBAC for Kubernetes authorisation on top with 'az aks update --resource-group <rg> --name <cluster> --enable-azure-rbac', and assign least-privilege built-in roles such as 'Azure Kubernetes Service RBAC Reader' rather than cluster-admin.
3. Enforce the standard fleet-wide by assigning the built-in policy 'Role-Based Access Control (RBAC) should be used on Kubernetes Services' in Audit mode so new non-compliant clusters surface in Defender for Cloud: pid=$(az policy definition list --query "[?displayName=='Role-Based Access Control (RBAC) should be used on Kubernetes Services'].name" -o tsv); az policy assignment create --name aks-rbac-required --policy "$pid" --scope <subscription-or-mg-scope>.

# Find the highest-risk privileged assignments first: external accounts and blocked leavers holding Owner.
SUB="00000000-0000-0000-0000-000000000000"

# List Owners, with type and object id, so external and group principals are obvious.
az role assignment list \
  --scope "/subscriptions/$SUB" \
  --role Owner \
  --query "[].{who:principalName, type:principalType, id:principalId}" -o table

# Remove an external partner's Owner assignment (work finished). Keep at least one Owner you control.
az role assignment delete \
  --assignee "[email protected]" \
  --role Owner \
  --scope "/subscriptions/$SUB"

# Remove a deprecated (blocked) account's role assignment by object id.
# Blocking the Entra sign-in does NOT remove the assignment; delete it explicitly.
az role assignment delete \
  --assignee-object-id "<blocked-user-object-id>" \
  --scope "/subscriptions/$SUB"

# Consolidate the remaining legitimate Owners behind one Entra group, then make it eligible
# (just-in-time) via Privileged Identity Management so nobody holds standing Owner.