AKS clusters created with Kubernetes RBAC turned off
What does ZopNight detect here?
ZopNight rates an AKS cluster critical when Azure reports `enableRBAC` as false, meaning Kubernetes role-based access control is switched off. Every authenticated identity then has the same unrestricted reach across namespaces, secrets and workloads. Kubernetes RBAC is on by default for new AKS clusters, so a finding usually marks an old cluster.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1351 |
| Category | compliance |
| Severity | critical |
| Metric | none — pure configuration read |
| Threshold | enableRBAC = false |
| Source | ZopNight |
| Permissions used | Microsoft.ContainerService/managedClusters/read |
Where it applies
Without RBAC there is only one level of access
Kubernetes RBAC is the Role, ClusterRole and RoleBinding model the API server uses to decide what an authenticated caller may do. Microsoft describes it as one of the two authorization models AKS supports, the other being Microsoft Entra ID authorization through Azure role assignments.
Turn RBAC off and that decision disappears. A developer’s kubeconfig, a CI service account and a platform administrator can all read every secret, change every deployment and delete any namespace. There is no smaller permission to grant, because the mechanism that scopes permissions is not running. That is why ZopNight rates this finding critical.
Finding clusters without RBAC
az aks list --query "[].{name:name, rg:resourceGroup, rbac:enableRbac}" -o tableAny False row is a cluster with Kubernetes RBAC disabled. For clusters that show True, the
aadProfile.enableAzureRbac field tells you whether Entra ID authorization is also on.
What ZopNight checks
The finding rests on the cluster’s enableRBAC property as Azure reports it. It fires only when
that property is explicitly false. No metric, window or workload count is involved, and a
cluster with RBAC on is never flagged by this rule regardless of how its roles are written.
Clusters left out
If the property is missing from Azure’s response, ZopNight does not assume RBAC is off and raises nothing for that cluster. Cluster tags that claim an RBAC state are ignored, since only Azure’s own record of the cluster’s authorization mode counts.
Because Kubernetes RBAC is enabled by default during AKS cluster creation,
a cluster that fires almost always predates that default or was created with
--disable-rbac on purpose.
A critical access-control gap with no dollar figure
There is no saving on this compliance finding. The exposure is a stolen or over-shared credential with administrator-equivalent reach over every workload in the cluster.
Replacing a cluster that has RBAC off
The --disable-rbac switch exists only on az aks create; az aks update offers no way to turn
Kubernetes RBAC on afterwards. The practical fix is a replacement cluster.
- Create the new cluster with RBAC left at its default and Microsoft Entra integration:
az aks create ... --enable-aad --enable-azure-rbac. - Assign the built-in roles (Azure Kubernetes Service RBAC Reader, Writer, Admin and Cluster Admin) to Entra users and groups at cluster or namespace scope, as described in Use Azure RBAC for Kubernetes authorization.
- Recreate any Kubernetes Roles and RoleBindings workloads depend on.
- Migrate workloads, cut traffic over and delete the old cluster.