Description
Kubernetes RBAC uses roles and bindings to limit which resources users and service accounts can read or modify. Turning it off with disableRBAC: true in Crossplane's AKSCluster makes it harder to separate permissions according to least privilege.
RBAC provides authorization, which is separate from authentication. Enabling it alone does not establish appropriate permissions; review the actual roles and bindings.
Potential impact
- Identities accessing the cluster may be able to read or change resources beyond their work requirements.
- Misuse of a user or service account may have a broader impact through changes to or deletion of important resources.
Remediation
- Set
disableRBACtofalsefor new clusters. Microsoft does not support enabling Kubernetes RBAC later on an existing non-RBAC cluster, so plan migration of that environment to a new cluster with RBAC enabled. - Configure roles and bindings that allow only required resources and operations, and remove unnecessary cluster-wide privileges.
- Test allowed and denied operations for users and service accounts before and after migration, and verify the application and data migration procedure.
Examples
These partial examples compare cluster creation settings in the existing Crossplane API. Other required settings, including nodes and networking, are omitted.
Before
apiVersion: compute.azure.crossplane.io/v1alpha3
kind: AKSCluster
spec:
location: eastus
nodeCount: 2
disableRBAC: true
This creation configuration disables Kubernetes RBAC.
After
apiVersion: compute.azure.crossplane.io/v1alpha3
kind: AKSCluster
spec:
location: eastus
nodeCount: 2
disableRBAC: false
This creation configuration enables Kubernetes RBAC. It is not an example of converting an existing non-RBAC cluster by changing this value alone; configure the required roles and bindings separately.