Usare l'autorizzazione di Microsoft Entra ID per l'API di Kubernetes in Servizio Azure Kubernetes (AKS)

Si applica a: ✔️ Servizio Azure Kubernetes Standard automatico ✔️ Servizio Azure Kubernetes standard

Questo articolo illustra come autorizzare le chiamate all'API Kubernetes in Servizio Azure Kubernetes (AKS) usando identità Microsoft Entra ID. L'autorizzazione di Microsoft Entra ID per l'API di Kubernetes usa le assegnazioni di ruolo di Azure RBAC per concedere l'accesso alle risorse di Kubernetes. Per le risorse Kubernetes integrate, assegna uno dei ruoli predefiniti di AKS, ad esempio servizio Azure Kubernetes RBAC Reader, a livello di cluster o di spazio dei nomi. Per le risorse personalizzate (CRD), assegnare un ruolo personalizzato con condizioni Azure ABAC che specificano i gruppi o i tipi di CRD a cui l'assegnatario ha accesso. Le due assegnazioni di ruolo costituiscono: una concede l'accesso alle risorse Kubernetes standard e l'altra concede l'accesso condizionale a risorse personalizzate specifiche.

Per la maggior parte dei carichi di lavoro di produzione, AKS Automatic è l'opzione predefinita consigliata e pronta per la produzione per AKS. I cluster automatici di AKS sono preconfigurati con Azure RBAC per l'autorizzazione in Kubernetes, così puoi concentrarti sull'assegnazione delle corrette assegnazioni di ruolo di Microsoft Entra a utenti, gruppi ed entità servizio.

Per una panoramica concettuale delle opzioni di autorizzazione dell'API Kubernetes disponibili nel servizio Azure Kubernetes, vedere Concetti relativi all'autorizzazione del cluster.

Prerequisites

• È necessaria l'interfaccia della riga di comando di Azure versione 2.24.0 o successiva installata e configurata. Eseguire az --version per trovare la versione. Se è necessario installare o aggiornare, vedere Installare interfaccia della riga di comando di Azure.
• È necessario kubectl, con una versione minima di 1.18.3.
• È necessaria l'integrazione Microsoft Entra gestita abilitata nel cluster prima di poter aggiungere Microsoft Entra ID autorizzazione per l'API Kubernetes. Se è necessario abilitare l'integrazione gestita di Microsoft Entra, consulta Usare Microsoft Entra ID in AKS.
• La propagazione delle nuove assegnazioni di ruolo può richiedere fino a cinque minuti, e possono essere aggiornate dal server di autorizzazione.
• L'autorizzazione di Microsoft Entra ID per l'API di Kubernetes richiede che il tenant Microsoft Entra configurato per l'autenticazione sia lo stesso tenant della sottoscrizione che contiene il cluster AKS.

Comportamento della modalità cluster di AKS

Creare un nuovo cluster AKS con integrazione gestita con Microsoft Entra e autorizzazione di Microsoft Entra ID

AKS Automatico (consigliato per i carichi di lavoro di produzione)

Per i nuovi carichi di lavoro di produzione, usa AKS Automatic. Azure RBAC per l'autorizzazione di Kubernetes è preconfigurato nei cluster Automatic di AKS.

1. Crea un cluster automatico di Servizio Azure Kubernetes (AKS) seguendo Creare un cluster automatico di Servizio Azure Kubernetes (AKS).

2. Facoltativo: verificare che il controllo degli accessi in base al ruolo di Azure per l'autorizzazione di Kubernetes sia abilitato nel cluster usando il comando az aks show.

   # Set environment variables
   export RESOURCE_GROUP=<resource-group-name>
   export CLUSTER_NAME=<cluster-name>
   
   az aks show \
     --resource-group $RESOURCE_GROUP \
     --name $CLUSTER_NAME \
     --query "aadProfile.enableAzureRbac" \
     --output tsv
   

Servizio Azure Kubernetes Standard

1. Creare un gruppo di risorse Azure usando il comando az group create.

   export RESOURCE_GROUP=<resource-group-name>
   export LOCATION=<azure-region>
   
   az group create --name $RESOURCE_GROUP --location $LOCATION
   

2. Crea un cluster AKS Standard con integrazione gestita di Microsoft Entra e autorizzazione di Microsoft Entra ID usando il comando az aks create.

   export CLUSTER_NAME=<cluster-name>
   
   az aks create \
       --resource-group $RESOURCE_GROUP \
       --name $CLUSTER_NAME \
       --enable-aad \
       --enable-azure-rbac \
       --generate-ssh-keys
   

   L'output dovrebbe essere simile all'esempio di output seguente:

   "AADProfile": {
       "adminGroupObjectIds": null,
       "clientAppId": null,
       "enableAzureRbac": true,
       "managed": true,
       "serverAppId": null,
       "serverAppSecret": null,
       "tenantId": "****-****-****-****-****"
   }
   

Abilitare l'autorizzazione di Microsoft Entra ID in un cluster AKS esistente

Per i cluster Standard di AKS esistenti, abilitare l'autorizzazione di Microsoft Entra ID per l'API Kubernetes usando il comando az aks update con il flag --enable-azure-rbac.

# Set environment variables
export RESOURCE_GROUP=<resource-group-name>
export CLUSTER_NAME=<cluster-name>

# Enable Microsoft Entra ID authorization for the Kubernetes API
az aks update --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --enable-azure-rbac

I cluster automatici di AKS hanno già Azure RBAC per l'autorizzazione di Kubernetes preconfigurato. Non è necessario eseguire --enable-azure-rbac per AKS Automatic.

Ruoli predefiniti di AKS

AKS fornisce i seguenti ruoli predefiniti:

Creare assegnazioni di ruolo per l'accesso al cluster

Creare definizioni di ruoli personalizzati

Per le risorse Kubernetes predefinite, le definizioni di ruolo personalizzate fanno riferimento all'azione del gruppo di API corrispondente in Microsoft.ContainerService/managedClusters/. L'esempio seguente consente a un utente di leggere solo le distribuzioni e nient'altro. Per l'elenco completo delle possibili azioni, vedere Operazioni di Microsoft.ContainerService. Per filtrare l'accesso a specifici gruppi o tipi di risorse personalizzate (CRD), consulta Restrict custom resource access using ABAC conditions più avanti in questo articolo.

1. Per creare definizioni di ruolo personalizzate, copiare il file seguente, sostituire <YOUR-SUBSCRIPTION-ID> con il proprio ID sottoscrizione e quindi salvarlo come deploy-view.json.

   {
       "Name": "AKS Deployment Reader",
       "Description": "Lets you view all deployments in cluster/namespace.",
       "Actions": [],
       "NotActions": [],
       "DataActions": [
           "Microsoft.ContainerService/managedClusters/apps/deployments/read"
       ],
       "NotDataActions": [],
       "assignableScopes": [
           "/subscriptions/<YOUR-SUBSCRIPTION-ID>"
       ]
   }
   

2. Creare la definizione del ruolo tramite il comando az role definition create, impostando --role-definition sul file deploy-view.json che è stato creato nel passaggio precedente.

   az role definition create --role-definition @deploy-view.json 
   

3. Assegnare la definizione di ruolo a un utente o a un'altra identità usando il az role assignment create comando .

       # Set environment variables
   export RESOURCE_GROUP=<resource-group-name>
   export CLUSTER_NAME=<cluster-name>
   
   # Get the AKS resource ID
   AKS_ID=$(az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query id --output tsv)
   
   # Create a role assignment for the AKS Deployment Reader role
   az role assignment create --role "AKS Deployment Reader" --assignee <AAD-ENTITY-ID> --scope $AKS_ID
   

Limitare l'accesso alle risorse personalizzate utilizzando le condizioni ABAC (anteprima)

Le condizioni di controllo degli accessi in base al ruolo consentono applicare dei filtri alle assegnazioni di ruolo Microsoft Entra ID a gruppi e tipologie di risorse personalizzate (CRD) specifiche, centralmente, da Microsoft Entra ID, senza la scrittura del controllo degli accessi in base al ruolo di Kubernetes per cluster Role e di manifesti RoleBinding. Per informazioni di base su ABAC di Azure, vedere Cosa sono le condizioni di assegnazione di ruolo di Azure?

Quando applicare le condizioni ABAC

Usare questa funzionalità quando si vuole:

• Limitare i gruppi o i tipi di CRD che un assegnatario può elencare o visualizzare.
• Applicare centralmente i limiti di accesso alle risorse personalizzate da Microsoft Entra ID senza la gestione del controllo degli accessi in base al ruolo di Kubernetes Role e oggetti RoleBinding in ogni cluster.
• Distinguere tra i CRD pubblicati da operatori diversi (ad esempio, consentire secrets-store.csi.x-k8s.io durante il blocco security.istio.io).

Attributi di condizione disponibili

Gli attributi di richiesta seguenti sono disponibili quando si creano condizioni per l'API Kubernetes in un cluster del servizio Azure Kubernetes:

Aggiungere una condizione ABAC a un'assegnazione di ruolo

L'esempio seguente crea un ruolo personalizzato AKS CRD Reader che concede l'accesso in lettura alle risorse personalizzate. Quindi assegna il ruolo con una condizione che consente l'accesso solo a secretproviderclasses nel gruppo secrets-store.csi.x-k8s.io (la CRD usata dal provider di Azure Key Vault per Secrets Store CSI Driver).

1. Salvare la definizione di ruolo seguente in un file denominato crd-reader.json, sostituendo <YOUR-SUBSCRIPTION-ID> con il proprio ID sottoscrizione.

   {
       "Name": "AKS CRD Reader",
       "Description": "Lets you read custom resources in the cluster.",
       "Actions": [],
       "NotActions": [],
       "DataActions": [
           "Microsoft.ContainerService/managedClusters/customresources/read"
       ],
       "NotDataActions": [],
       "assignableScopes": [
           "/subscriptions/<YOUR-SUBSCRIPTION-ID>"
       ]
   }
   

2. Creare la definizione del ruolo usando il az role definition create comando .

   az role definition create --role-definition @crd-reader.json
   

3. Salvare la condizione seguente in un file denominato abac-condition.txt. La condizione consente alle letture di risorse non customizzate di passare senza modifiche e limita le letture di risorse customizzate a un gruppo e un tipo specifici.

   (
    (
     !(ActionMatches{'Microsoft.ContainerService/managedClusters/customresources/read'})
    )
    OR
    (
     @Request[Microsoft.ContainerService/managedClusters/customResources:group] StringEqualsIgnoreCase 'secrets-store.csi.x-k8s.io'
     AND
     @Request[Microsoft.ContainerService/managedClusters/customResources:kind] StringEqualsIgnoreCase 'secretproviderclasses'
    )
   )
   

4. Creare l'assegnazione di ruolo con la condizione usando il comando az role assignment create.

   # Set environment variables
   export RESOURCE_GROUP=<resource-group-name>
   export CLUSTER_NAME=<cluster-name>
   
   # Get the AKS resource ID
   AKS_ID=$(az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query id --output tsv)
   
   # Create a role assignment for the AKS CRD Reader role with an ABAC condition
   az role assignment create \
       --role "AKS CRD Reader" \
       --assignee <AAD-ENTITY-ID> \
       --scope $AKS_ID \
       --condition "$(cat abac-condition.txt)" \
       --condition-version "2.0" \
       --description "Allow reads on SecretProviderClass resources only"
   

È anche possibile aggiungere una condizione tramite il portale di Azure. Nella pagina Aggiungi assegnazione di ruolo selezionare la scheda Condizioni , quindi selezionare Aggiungi condizione e usare l'editor visivo per compilare l'espressione.

Verificare la condizione

In seguito alla propagazione dell'assegnazione di ruolo (fino a cinque minuti), eseguire l'accesso come assegnatario e confermare la possibilità di leggere le definizioni di risorse personalizzate (CRD) consentite ma non le altre.

1. Ottenere le credenziali del cluster usando il az aks get-credentials comando .

   # Set environment variables
   export RESOURCE_GROUP=<resource-group-name>
   export CLUSTER_NAME=<cluster-name>
   
   # Get the cluster credentials
   az aks get-credentials --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME
   

2. Elencare secretproviderclasses dal gruppo secrets-store.csi.x-k8s.io, che è consentito dalla condizione. Il comando deve avere esito positivo e restituire le risorse esistenti o un elenco vuoto oppure un errore non trovato se il CRD non è installato nel cluster.

   kubectl get secretproviderclasses.secrets-store.csi.x-k8s.io --all-namespaces
   

3. Elencare authorizationpolicies dal gruppo Istio security.istio.io, che è consentito dalla condizione. Il comando deve avere esito negativo con un Forbidden errore del webhook di autorizzazione Microsoft Entra ID (presupponendo che il CRD Istio sia installato nel cluster; in caso contrariokubectl, restituisce un errore non trovato prima che il server API raggiunga il webhook di autorizzazione).

   kubectl get authorizationpolicies.security.istio.io --all-namespaces
   

Pulire le risorse

Disabilitare l'autorizzazione Microsoft Entra ID

Rimuovi l'autorizzazione di Microsoft Entra ID usando il comando az aks update con il flag --disable-azure-rbac.

# Set environment variables
export RESOURCE_GROUP=<resource-group-name>
export CLUSTER_NAME=<cluster-name>

# Disable Microsoft Entra ID authorization for the Kubernetes API
az aks update --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --disable-azure-rbac

Eliminare l'assegnazione di ruolo

Eliminare la definizione del ruolo

Eliminare una definizione di ruolo personalizzata usando il az role definition delete comando .

az role definition delete --name "AKS Deployment Reader"

Eliminare il gruppo di risorse e il cluster AKS

# Set environment variables
export RESOURCE_GROUP=<resource-group-name>

# Delete the resource group and all resources in it
az group delete --name $RESOURCE_GROUP --yes --no-wait

Contenuti correlati

Per saperne di più su AKS (Azure Kubernetes Service), vedere gli articoli seguenti:

• Che cos'è AKS Automatic?
• Creare un cluster automatico di AKS
• Concetti di autorizzazione del cluster per AKS
• Opzioni di accesso e identità per AKS
• Cos'è Azure RBAC (controllo degli accessi in base al ruolo)?
• Che cosa sono le condizioni ABAC di Azure?
• Operazioni di Microsoft.ContainerService