# AKS Cluster RBAC Not Enabled

> 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.

Source: https://zop.dev/integrations/azure/recommendations/aks-cluster-rbac-not-enabled
Updated: 2026-08-19

---

## 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

```bash
az aks list --query "[].{name:name, rg:resourceGroup, rbac:enableRbac}" -o table
```

Any `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.