AKS clusters with Kubernetes RBAC enforce authorization through roles and bindings mapped to identities and groups.
This evaluates whether the cluster has RBAC enabled to control access to namespaces and cluster-wide resources.
Risk
Without Kubernetes RBAC, authorization becomes overly broad, weakening least privilege. Compromised credentials could read secrets, alter workloads, or delete services, impacting confidentiality, integrity, and availability, and enabling lateral movement across the cluster.
prowler azure --checks aks_cluster_rbac_enabled
Recommendation
Enable Kubernetes RBAC and design permissions with least privilege: scope roles to namespaces, grant access via groups, apply deny-by-default, and separate duties for admins and operators.
Integrate with Microsoft Entra ID and review/audit role bindings to maintain defense in depth.
Remediation
- In Azure portal, go to Kubernetes services > Create (or edit your deployment template)
- On the Authentication tab, set Kubernetes RBAC to Enabled
- Review + Create to deploy (re-create the cluster if the setting can't be changed on an existing one)
Source Code
Resource Type
microsoft.containerservice/managedclusters
References
- https://learn.microsoft.com/en-us/security/benchmark/azure/security-controls-v2-privileged-access#pa-7-follow-just-enough-administration-least-privilege-principle
- https://www.trendmicro.com/cloudoneconformity/knowledge-base/azure/AKS/enable-role-based-access-control-for-kubernetes-service.html#
- https://learn.microsoft.com/en-us/azure/aks/azure-ad-rbac?tabs=portal