> ## Documentation Index > Fetch the complete documentation index at: https://cloudanix.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Use Azure RBAC For Kubernetes Authorization ### More Info: Use Azure RBAC for Kubernetes authorization so access decisions are enforced through Azure role assignments rather than only native Kubernetes RBAC. ### Risk Level High ### Address Security ### Compliance Standards * CIS AKS ### Triage and Remediation ### Remediation 1. **Identify the cluster and control plane config** * Run on any machine with Azure CLI access: ```bash theme={null} az account show --output table az aks list --output table ``` * Note the `resourceGroup` and `name` of the AKS cluster you’re reviewing. 2. **Check whether Azure RBAC for Kubernetes authorization is enabled** * Run on any machine with Azure CLI access: ```bash theme={null} az aks show \ --resource-group \ --name \ --query '{azureRBACEnabled: azureRBACEnabled, \ azurePortalFQDN: azurePortalFQDN, \ oidcIssuerProfile: oidcIssuerProfile}' \ --output json ``` * If `azureRBACEnabled` is `true`, Azure RBAC for Kubernetes authorization is already enabled; go to step 6 to review role assignments. If it is `false` or missing, proceed to step 3. 3. **Decide whether to adopt Azure RBAC for Kubernetes authorization** * Gather current consumers and access models: * List service principals and managed identities used by workloads and admins: ```bash theme={null} az ad sp list --all --query "[].{appId:appId,displayName:displayName}" --output table ``` * Identify current Kubernetes-native RBAC bindings (for impact awareness): ```bash theme={null} kubectl get clusterrolebindings -A kubectl get rolebindings -A ``` * Decide if your organization wants Azure AD identities and Azure RBAC to be the primary authorization mechanism for cluster access (typically recommended for centralized governance and auditing). 4. **Plan and, if approved, enable Azure RBAC for Kubernetes authorization** * Review official Azure AKS documentation to confirm current prerequisites, limitations, and feature flags for your AKS version (for example, relation to AAD integration and OIDC issuer). * If your governance process approves, enable Azure RBAC using Azure Portal or CLI (conceptually: edit the AKS cluster to turn on “Azure RBAC for Kubernetes authorization”). Ensure a maintenance window is in place because this changes how access is evaluated. * After enabling, re-run step 2 to confirm `azureRBACEnabled` is now `true`. 5. **Define and assign Azure roles for Kubernetes access** * Identify which Azure built-in roles (for example, *Azure Kubernetes Service RBAC Cluster Admin*, *Azure Kubernetes Service RBAC Admin*, *Azure Kubernetes Service RBAC Writer*, *Azure Kubernetes Service RBAC Reader*) or custom roles should be used. * Assign them to Azure AD users, groups, or service principals at the appropriate scope (subscription, resource group, or AKS resource). Example to view current role assignments for the cluster resource: ```bash theme={null} az role assignment list \ --scope $(az aks show \ --resource-group \ --name \ --query id -o tsv) \ --output table ``` 6. **Verify effective access and ongoing posture** * From an Azure AD user or identity that should have cluster access via Azure RBAC, obtain credentials and test: ```bash theme={null} az aks get-credentials \ --resource-group \ --name \ --overwrite-existing kubectl auth can-i get pods --all-namespaces kubectl auth can-i create deployments -n default ``` * Confirm that allowed/denied operations match the Azure role assignments. Periodically review step 5’s role assignment listing to ensure only intended identities have Kubernetes access via Azure RBAC. kubectl cannot enable or configure Azure RBAC for Kubernetes authorization because this setting is managed at the Azure AKS control‑plane level (portal/CLI/IaC), not via Kubernetes API objects. To address this finding, follow the guidance in the Manual Steps section using the Azure portal, Azure CLI, or your IaC tooling. ```bash theme={null} #!/usr/bin/env bash set -euo pipefail # PURPOSE: # Report whether each AKS cluster in a subscription is using Azure RBAC for # Kubernetes authorization and whether native Kubernetes RBAC is enabled. # REQUIREMENTS: # - Azure CLI (az) # - jq # - Logged in: az login # - Proper role to read AKS clusters in the subscription(s) # CONFIGURABLE: list of subscriptions to inspect SUBSCRIPTIONS=($(az account list --query '[].id' -o tsv)) echo "subscription_id,resource_group,cluster_name,azure_rbac_enabled,local_accounts_disabled,rbac_enabled,notes" for SUB in "${SUBSCRIPTIONS[@]}"; do az account set --subscription "$SUB" >/dev/null # List all AKS clusters in this subscription while IFS= read -r CLUSTER; do RG=$(echo "$CLUSTER" | jq -r '.resourceGroup') NAME=$(echo "$CLUSTER" | jq -r '.name') # Get detailed cluster properties DETAILS=$(az aks show -g "$RG" -n "$NAME" -o json) # Azure RBAC flag (https://learn.microsoft.com/azure/aks/manage-azure-rbac) AZURE_RBAC_ENABLED=$(echo "$DETAILS" \ | jq -r '.azurePortalFQDN as $p | .azurePortalFQDN | .azureActiveDirectory?.roleBasedAccessControl?.azureRBACEnabled // .azureActiveDirectory?.azureRbacEnabled // "unknown"') # Local accounts (kubeconfig admin credentials); disabling them is often paired with Azure RBAC LOCAL_ACCOUNTS_DISABLED=$(echo "$DETAILS" \ | jq -r '.disableLocalAccounts // "unknown"') # Native Kubernetes RBAC flag RBAC_ENABLED=$(echo "$DETAILS" \ | jq -r '.enableRbac // "unknown"') NOTES="" # High‑level interpretation for reviewers if [ "$AZURE_RBAC_ENABLED" = "true" ]; then if [ "$RBAC_ENABLED" = "true" ]; then NOTES="Azure RBAC enabled; cluster also has native RBAC (expected: Azure RBAC is primary, but native RBAC still applies)." elif [ "$RBAC_ENABLED" = "false" ]; then NOTES="Azure RBAC enabled; native RBAC disabled (uncommon; review carefully)." else NOTES="Azure RBAC enabled; native RBAC state unknown." fi elif [ "$AZURE_RBAC_ENABLED" = "false" ]; then if [ "$RBAC_ENABLED" = "true" ]; then NOTES="Azure RBAC DISABLED; cluster relies only on native Kubernetes RBAC. REVIEW against CISAKS 5.5.2." elif [ "$RBAC_ENABLED" = "false" ]; then NOTES="Both Azure RBAC and native RBAC appear disabled; configuration likely invalid, review immediately." else NOTES="Azure RBAC disabled; native RBAC state unknown, review manually." fi else NOTES="Azure RBAC state unknown; cluster may be legacy or API changed, review manually." fi # CSV output echo "\"$SUB\",\"$RG\",\"$NAME\",\"$AZURE_RBAC_ENABLED\",\"$LOCAL_ACCOUNTS_DISABLED\",\"$RBAC_ENABLED\",\"$NOTES\"" done < <(az aks list -o json | jq -c '.[]') done ``` How to run (any machine with Azure CLI access): ```bash theme={null} chmod +x report-aks-azure-rbac.sh ./report-aks-azure-rbac.sh > aks-azure-rbac-report.csv ``` What indicates a potential problem with respect to CISAKS 5.5.2: * Rows where: * `azure_rbac_enabled` is `false` or `unknown`, and * `rbac_enabled` is `true`\ → The cluster is using only native Kubernetes RBAC; review whether Azure RBAC should be adopted. * Rows where: * `azure_rbac_enabled` is `false`, and * `rbac_enabled` is `false`\ → Misconfigured or legacy cluster; access control model must be reviewed urgently. * Any row with `azure_rbac_enabled` = `unknown`\ → The script could not reliably detect the Azure RBAC setting; inspect this cluster in the Azure portal/CLI manually.