AKS clusters running with Kubernetes RBAC turned off
What does ZopNight detect here?
Kubernetes RBAC disabled on an AKS cluster gives every authenticated identity unrestricted access to all cluster resources, so ZopNight rates rule RC-1351 critical. Detection reads rbac_enabled, derived from the cluster's enableRBAC property, and fires only on an explicit "false". Since AKS has defaulted RBAC on since 2020, findings usually mean a legacy cluster.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1351 |
| Category | compliance |
| Severity | critical |
| Metric | none — pure configuration read |
| Source | aks_rbac.go |
Where it applies
Every authenticated user is cluster-admin
With Kubernetes RBAC off, authorization inside the cluster simply does not happen: any identity that can authenticate (every developer with cluster credentials, every workload service account) can read every secret, modify every deployment, and delete anything in any namespace. A stolen CI token has the same reach as a platform administrator. There is no smaller privilege to grant, because the mechanism that would scope it is disabled. That is why this is one of the few findings ZopNight rates critical.
Proof from enableRBAC
The discoverer surfaces the cluster’s properties.enableRBAC through Azure Resource Graph,
a read the built-in Reader role covers, and stamps it as rbac_enabled metadata. Rule
RC-1351 fires only when the value is an explicit "false". An absent value abstains, and the
rule never consults tags: its predecessor keyed on an rbac tag that nothing produced, which
meant the check silently never ran. The current read is Azure’s own report of the cluster’s
authorization mode.
Confirm RBAC state on your clusters
az aks list --query "[].{name:name, rg:resourceGroup, rbac:enableRbac}" -o tableAny false row is a cluster where authorization is off entirely.
Why findings are rare in 2026
Kubernetes RBAC has been enabled by default on every new AKS cluster since 2020, and the
--enable-rbac flag is now a deprecated no-op. A cluster that fires this rule is therefore
almost certainly an old one, created before the default changed and never rebuilt. Often it is
exactly the cluster with the most accumulated workloads and the least appetite for
disruption. Turning RBAC on is not an in-place toggle; the realistic remediation is a
replacement cluster and a migration.
The modern lever: Azure RBAC and Entra ID
For the rebuild, plain Kubernetes RBAC is the floor, not the target. Creating the cluster
with --enable-aad and --enable-azure-rbac integrates Microsoft Entra ID and lets you
assign the built-in Azure Kubernetes Service RBAC Reader, Writer, Admin and Cluster Admin
roles to real users and groups; access reviews and offboarding then happen in one identity
system instead of scattered ClusterRoleBindings. Kubernetes-side Role and RoleBinding
resources remain available for the fine-grained cases underneath.