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

Remediation

Manual Steps

1. Identify the cluster and control plane config

   • Run on any machine with Azure CLI access:
     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:
     az aks show \
       --resource-group <RESOURCE_GROUP_NAME> \
       --name <CLUSTER_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:
       az ad sp list --all --query "[].{appId:appId,displayName:displayName}" --output table
       
     • Identify current Kubernetes-native RBAC bindings (for impact awareness):
       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:
     az role assignment list \
       --scope $(az aks show \
         --resource-group <RESOURCE_GROUP_NAME> \
         --name <CLUSTER_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:
     az aks get-credentials \
       --resource-group <RESOURCE_GROUP_NAME> \
       --name <CLUSTER_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.

Using kubectl

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.

Automation

#!/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):

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.