Use Azure Rbac Kubernetes Authorization

More Info:

It is Best Practice to restrict or fence untrusted workloads when running in a multi-tenant environment.

Risk Level

Low

Address

Security

Compliance Standards

• CIS AKS

Triage and Remediation

Remediation

Remediation

Manual Steps

1. Confirm cluster is Azure RBAC‑capable

   • From any machine with az and kubectl configured, identify the cluster:

     az account show --output table
     az aks list --output table

   • Note the resource group and cluster name you are assessing.

2. Check whether Azure RBAC for Kubernetes is enabled

   • Run:

     az aks show \
       --resource-group <RESOURCE_GROUP_NAME> \
       --name <CLUSTER_NAME> \
       --query "{azureRbac:azureRBACEnabled, aadProfile:azureActiveDirectory, oidcIssuerProfile:oidcIssuerProfile}" \
       --output json

   • Interpretation:
     • "azureRbac": true → Azure RBAC for Kubernetes authorization is enabled.
     • "azureRbac": false or missing → legacy Kubernetes RBAC-only model is in use.

3. Review who gets cluster access via Azure RBAC (role assignments)

   • For the AKS cluster resource, list current Azure role assignments (from any machine with az):

     az aks show \
       --resource-group <RESOURCE_GROUP_NAME> \
       --name <CLUSTER_NAME> \
       --query id \
       --output tsv

     az role assignment list \
       --scope "<AKS_RESOURCE_ID>" \
       --output table

   • Evaluate:
     • Are there broad assignments (e.g., Owner, Contributor, or Azure Kubernetes Service RBAC Cluster Admin to large groups such as “All Users”)?
     • Are least‑privilege roles used (e.g., Azure Kubernetes Service RBAC Reader, Azure Kubernetes Service RBAC Writer) for regular tenants?

4. Inspect Kubernetes RBAC for multi‑tenant scoping (authorization model in effect)

   • If Azure RBAC is enabled, verify that Kubernetes native RBAC is not relied upon for primary tenant isolation:

     kubectl get clusterrolebindings,rolebindings -A

     • Look for overly permissive bindings mapped to Azure AD identities/groups that already have powerful Azure RBAC roles; avoid duplicating “cluster‑admin” access.
   • If Azure RBAC is not enabled, review whether Kubernetes RBAC is being used to appropriately fence tenants into their own namespaces with least privilege.

5. Decide and implement the authorization model change (console/CLI/IaC)

   • If Azure RBAC for Kubernetes should be enabled for this cluster:
     • Through Azure Portal: navigate to the AKS cluster → Settings → Access control (IAM) / Configuration and follow Microsoft guidance to enable Azure RBAC for Kubernetes authorization and, if appropriate, AKS‑managed Azure AD integration.
     • Or via CLI (for a cluster that supports update):

       az aks update \
         --resource-group <RESOURCE_GROUP_NAME> \
         --name <CLUSTER_NAME> \
         --enable-azure-rbac

     • Update your IaC (e.g., ARM/Bicep/Terraform) so future deployments keep azureRBACEnabled (or equivalent) set.
   • If you intentionally do not enable Azure RBAC, document the rationale and ensure Kubernetes RBAC and network policies adequately fence tenants.

6. Re‑verify and document the posture

   • After any change, re‑run:

     az aks show \
       --resource-group <RESOURCE_GROUP_NAME> \
       --name <CLUSTER_NAME> \
       --query "{azureRbac:azureRBACEnabled}" \
       --output json

   • Confirm role assignments reflect least privilege:

     az role assignment list \
       --scope "<AKS_RESOURCE_ID>" \
       --output table

   • Record which model (Azure RBAC, Kubernetes RBAC, or hybrid) is in use, how tenants are fenced (namespaces, roles, network policies), and who has admin‑level access.

Using kubectl

kubectl cannot configure Azure RBAC for Kubernetes authorization because this setting is managed at the Azure AKS control plane level via the Azure portal, Azure CLI, or IaC (ARM/Bicep/Terraform). Refer to the Manual Steps section for guidance on reviewing and configuring Azure RBAC for your cluster.

Automation

#!/usr/bin/env bash
#
# Report whether an AKS cluster is using Azure RBAC for Kubernetes authorization
# and summarize Kubernetes RBAC objects for review.
#
# Run this on any machine with:
#   - az CLI authenticated to the correct subscription/tenant
#   - kubectl configured for the target cluster context

set -euo pipefail

# -----------------------------
# Helper: print section header
# -----------------------------
section() {
  echo
  echo "============================================================"
  echo "$1"
  echo "============================================================"
}

# -----------------------------
# 1) Identify current AKS cluster context
# -----------------------------
section "1) kubectl context and cluster info"

kubectl config current-context || {
  echo "ERROR: kubectl context not set"; exit 1;
}

kubectl cluster-info || {
  echo "ERROR: cannot reach cluster with kubectl"; exit 1;
}

# -----------------------------
# 2) Detect AKS cluster resource in Azure
#    (we infer from current context; adjust if needed)
# -----------------------------
section "2) Resolve AKS cluster in Azure based on kubectl context"

CTX="$(kubectl config current-context)"

# Try to parse resource group and cluster name from common AKS context patterns.
# If your context naming is different, override AKS_RG and AKS_NAME manually.
AKS_RG=""
AKS_NAME=""

# Example context patterns:
#   - "aks-CLUSTER_NAME" (no RG info)
#   - "CLUSTER_NAME" only
# Because patterns vary by environment, we just prompt if we cannot auto-detect.

echo "Current kubectl context: ${CTX}"
echo "Attempting to list AKS clusters so you can select the correct one..."
echo

az account show >/dev/null 2>&1 || {
  echo "ERROR: 'az' CLI not logged in. Run: az login"; exit 1;
}

az aks list -o table

echo
read -r -p "Enter AKS resource group name: " AKS_RG
read -r -p "Enter AKS cluster name: " AKS_NAME

if [[ -z "$AKS_RG" || -z "$AKS_NAME" ]]; then
  echo "ERROR: AKS_RG and AKS_NAME must be provided"; exit 1;
fi

# -----------------------------
# 3) Check whether Azure RBAC for Kubernetes Authorization is enabled
# -----------------------------
section "3) Azure RBAC for Kubernetes Authorization setting"

az aks show \
  --resource-group "$AKS_RG" \
  --name "$AKS_NAME" \
  --query "aadProfile" \
  -o json | jq .

# More focused queries:
echo
echo "Key flags (null/false typically indicate Azure RBAC is NOT in use):"
echo

echo "- aadProfile.enableAzureRBAC:"
az aks show \
  --resource-group "$AKS_RG" \
  --name "$AKS_NAME" \
  --query "aadProfile.enableAzureRBAC" \
  -o tsv

echo "- aadProfile.managed (AAD integration managed by AKS):"
az aks show \
  --resource-group "$AKS_RG" \
  --name "$AKS_NAME" \
  --query "aadProfile.managed" \
  -o tsv

echo "- aadProfile.tenantId:"
az aks show \
  --resource-group "$AKS_RG" \
  --name "$AKS_NAME" \
  --query "aadProfile.tenantId" \
  -o tsv

cat <<'EOF'

INTERPRETATION (for review, not an automated pass/fail):

- If 'aadProfile.enableAzureRBAC' is:
    - 'true'  -> Azure RBAC for Kubernetes authorization is enabled.
    - 'false' or empty/null -> Azure RBAC for Kubernetes authorization is NOT enabled;
      Kubernetes-native RBAC only is used.

- If 'aadProfile' itself is null or mostly empty, the cluster may not be using AAD
  or Azure RBAC. This is usually NOT aligned with the best practice of using Azure
  RBAC for Kubernetes in multi-tenant/untrusted scenarios.

This does NOT automatically mean the configuration is wrong; it must be evaluated
against your threat model and tenancy requirements.

EOF

# -----------------------------
# 4) Summarize Kubernetes RBAC configuration (for context)
# -----------------------------
section "4) Summary of Kubernetes RBAC objects (cluster-wide)"

echo "[ClusterRoles] (names only):"
kubectl get clusterroles -o custom-columns=NAME:.metadata.name --no-headers | sort

echo
echo "[ClusterRoleBindings] (who gets cluster-wide permissions):"
kubectl get clusterrolebindings -o wide

echo
echo "[Roles] (per-namespace, count by namespace):"
kubectl get roles --all-namespaces -o json \
  | jq -r '.items[].metadata.namespace' \
  | sort | uniq -c | sort -nr

echo
echo "[RoleBindings] (per-namespace, count by namespace):"
kubectl get rolebindings --all-namespaces -o json \
  | jq -r '.items[].metadata.namespace' \
  | sort | uniq -c | sort -nr

cat <<'EOF'

INTERPRETATION (for review):

Potential red flags to investigate manually:
- Very broad ClusterRoles (e.g., 'cluster-admin' or custom roles with '*'
  verbs/resources) bound to:
  - ServiceAccounts used by untrusted or multi-tenant workloads.
  - Groups or users that represent many tenants or external identities.

- Many RoleBindings/ClusterRoleBindings granting elevated access to workloads
  that are supposed to be tightly isolated.

This script does NOT automatically determine if the configuration is acceptable.
Use it to quickly discover the current posture and then review bindings and roles
in detail.

EOF

# -----------------------------
# 5) Focused view: bindings granting cluster-admin
# -----------------------------
section "5) Cluster-admin bindings (high-privilege subjects)"

echo "[ClusterRoleBindings that reference 'cluster-admin']"
kubectl get clusterrolebindings -o json \
  | jq -r '
    .items[]
    | select(.roleRef.kind=="ClusterRole" and .roleRef.name=="cluster-admin")
    | "NAME: \(.metadata.name)\n  SUBJECTS:\n" +
      ( .subjects // [] | map("    - kind: \(.kind) name: \(.name) namespace: \(.namespace // \"-\")") | join("\n") )
  '

cat <<'EOF'

INTERPRETATION (for review):

- Any untrusted or multi-tenant workload identity (ServiceAccount, user, or group)
  appearing here with 'cluster-admin' is a strong indicator of over-privilege.
- In a design where Azure RBAC should be the primary authorization mechanism,
  review whether such cluster-admin grants are really required or could be
  narrowed/scoped.

EOF

# -----------------------------
# 6) Verification summary
# -----------------------------
section "6) What indicates a potential problem?"

cat <<'EOF'
You should flag the cluster for detailed review when you observe ANY of:

1) Azure RBAC for Kubernetes Authorization appears disabled:
   - 'aadProfile.enableAzureRBAC' is 'false', empty, or 'aadProfile' is null,
     yet the cluster is used for:
       - multi-tenant workloads, or
       - workloads from untrusted parties, or
       - workloads requiring strict isolation.

2) Kubernetes RBAC is very broad:
   - Many bindings to 'cluster-admin' or other highly privileged roles.
   - ServiceAccounts used by untrusted pods bound to ClusterRoles with wide
     permissions (e.g., verbs/resources set to '*').

3) Inconsistent model:
   - Azure RBAC is enabled but there are still numerous legacy static Kubernetes
     RBAC grants that bypass the intended Azure RBAC-based control model.

These findings do NOT automatically mean non-compliance; they highlight cases
where the design should be consciously validated against your multi-tenancy and
isolation requirements.

EOF

Additional Reading:

• https://docs.aws.amazon.com/eks/latest/userguide/fargate.html