Usare l'autorizzazione Microsoft Entra ID per l'API di Kubernetes in AKS

Questo articolo illustra come autorizzare le chiamate all'API Kubernetes nel servizio Azure Kubernetes usando le identità id di Microsoft Entra. L'autorizzazione Entra ID per l'API Kubernetes usa le assegnazioni dei ruoli di controllo degli accessi basate su Azure RBAC per concedere l'accesso alle risorse Kubernetes. Per le risorse Kubernetes predefinite, assegnare uno dei ruoli predefiniti di Azure Kubernetes Service (ad esempio Azure Kubernetes Service RBAC Reader) nell'ambito del cluster o dello 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 una panoramica concettuale delle opzioni di autorizzazione dell'API Kubernetes disponibili nel servizio Azure Kubernetes, vedere Concetti relativi all'autorizzazione del cluster.

Note

Quando si usa l'autenticazione integrata tra Microsoft Entra ID e AKS, è possibile usare utenti, gruppi o entità servizio di Microsoft Entra come soggetti in Kubernetes role-based access control (Kubernetes RBAC). Con l'autorizzazione entra ID non è necessario gestire separatamente le identità utente e le credenziali per Kubernetes. Tuttavia, è comunque necessario configurare e gestire le assegnazioni di ruolo Entra ID e le associazioni di RBAC di Kubernetes separatamente.

Prima di iniziare

È 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 Azure CLI.
È necessario kubectl, con una versione minima di 1.18.3.
È necessario abilitare l'integrazione di Microsoft Entra gestita nel cluster prima di poter aggiungere l'autorizzazione Entra ID 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 essere aggiornate dal server di autorizzazione.
L'autorizzazione entra ID per l'API Kubernetes richiede che il tenant di Microsoft Entra configurato per l'autenticazione sia lo stesso del tenant per la sottoscrizione che contiene il cluster del servizio Azure Kubernetes.

Creare un nuovo cluster di Azure Kubernetes Service (AKS) con l'integrazione gestita di Microsoft Entra e l'autorizzazione Entra ID

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

Creare un cluster AKS con integrazione gestita di Microsoft Entra e autorizzazione 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 Entra ID su un cluster AKS esistente.

Abilitare l'autorizzazione Entra ID per l'API Kubernetes in un cluster AKS esistente tramite il comando az aks update con l'opzione --enable-azure-rbac.
```
az aks update --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --enable-azure-rbac
```

Ruoli predefiniti di AKS

AKS fornisce i seguenti ruoli predefiniti:

Ruolo	Description
Lettore del controllo degli accessi in base al ruolo del servizio Azure Kubernetes	Consente l'accesso in sola lettura per visualizzare la maggior parte degli oggetti in un namespace. Non consente la visualizzazione di ruoli o associazioni di ruolo. Questo ruolo non consente la visualizzazione di `Secrets`, poiché la lettura del contenuto dei Segreti consente l'accesso alle credenziali di ServiceAccount nello spazio dei nomi, che permette l'accesso all'API impersonando qualsiasi ServiceAccount nello spazio dei nomi (un'escalation di privilegi).
Writer del controllo degli accessi in base al ruolo del servizio Azure Kubernetes	Consente l'accesso in lettura e scrittura alla maggior parte degli oggetti in un namespace. Questo ruolo non consente la visualizzazione o la modifica di ruoli o associazioni di ruoli. Tuttavia, questo ruolo consente di accedere a `Secrets` e eseguire i pod come qualsiasi ServiceAccount nel namespace, così da potere ottenere i livelli di accesso API di qualsiasi ServiceAccount nel namespace.
Amministratore del controllo degli accessi in base al ruolo del servizio Azure Kubernetes	Consente l'accesso amministrativo, destinato a essere concesso all'interno di un namespace. Consente l'accesso in lettura/scrittura alla maggior parte delle risorse in uno spazio dei nomi (o ambito del cluster), inclusa la possibilità di creare ruoli e associazioni di ruolo all'interno dello spazio dei nomi. Questo ruolo non consente l'accesso in scrittura alla quota di risorse o allo spazio dei nomi stesso.
Amministratore del cluster RBAC del servizio Azure Kubernetes	Consente all'utente con privilegi avanzati di eseguire qualsiasi azione su qualsiasi risorsa. Offre il controllo completo su ogni risorsa nel cluster e in tutti gli spazi dei nomi.

Creare assegnazioni di ruolo per l'accesso al cluster

Interfaccia della riga di comando di Azure
Portale di Azure

Ottieni l'ID risorsa di AKS usando il comando az aks show.

AKS_ID=$(az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query id --output tsv)

Creare un'assegnazione di ruolo usando il az role assignment create comando . <AAD-ENTITY-ID> può essere un nome utente o l'ID client di un'entità servizio. L'esempio seguente crea un'assegnazione per il ruolo di amministratore RBAC del servizio Azure Kubernetes.
```
az role assignment create --role "Azure Kubernetes Service RBAC Admin" --assignee <AAD-ENTITY-ID> --scope $AKS_ID
```
Note

È possibile creare le assegnazioni di ruolo Azure Kubernetes Service RBAC Reader e Azure Kubernetes Service RBAC Writer con ambito a uno spazio dei nomi specifico all'interno del cluster utilizzando il comando az role assignment create e impostando l'ambito sullo spazio dei nomi desiderato.
```
az role assignment create --role "Azure Kubernetes Service RBAC Reader" --assignee <AAD-ENTITY-ID> --scope $AKS_ID/namespaces/<namespace-name>
```

Nel portale di Azure, passare al cluster del servizio Azure Kubernetes.
Nel menu del servizio selezionare Controllo di accesso (IAM)>Aggiungi assegnazione di ruolo.
Nella scheda Ruolo, selezionare il ruolo desiderato, come Amministratore RBAC del servizio Azure Kubernetes, e quindi selezionare Avanti.
Nella scheda Membri configurare le impostazioni seguenti:
- Assegnare l'accesso a: selezionare Utente, gruppo o principale di servizio.
- Membri: selezionare + Seleziona membri, cercare e selezionare i membri desiderati e quindi selezionare Seleziona.
Selezionare Rivedi e assegna>Assegna.
Note

Nel portale di Azure, dopo aver creato assegnazioni di ruolo con ambito a uno spazio dei nomi desiderato, non sarà possibile visualizzare le "assegnazioni di ruolo" per lo spazio dei nomi in un ambito. È possibile trovarla usando il az role assignment list comando o elencare le assegnazioni di ruolo per un utente o un gruppo a cui è stato assegnato il ruolo.
```
az role assignment list --scope $AKS_ID/namespaces/<namespace-name>
```

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.

Per creare definizioni di ruolo personalizzate, copiare il file seguente, sostituendo <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>"
    ]
}

Creare la definizione del ruolo usando il az role definition create comando , impostando su --role-definition il deploy-view.json file creato nel passaggio precedente.
```
az role definition create --role-definition @deploy-view.json 
```
Assegnare la definizione di ruolo a un utente o a un'altra identità usando il az role assignment create comando .
```
az role assignment create --role "AKS Deployment Reader" --assignee <AAD-ENTITY-ID> --scope $AKS_ID
```

Restrigere l'accesso alle risorse personalizzate usando le condizioni del controllo degli accessi basato sugli attributi (anteprima)

Importante

Le funzionalità di anteprima di AKS sono disponibili su base self-service, su scelta. Le anteprime vengono fornite "così come sono" e "come disponibili" e sono escluse dai contratti di servizio e dalla garanzia limitata. Le anteprime del servizio Azure Kubernetes sono parzialmente coperte dal supporto clienti con la massima diligenza possibile. Di conseguenza, queste funzionalità non sono destinate all'uso in produzione. Per altre informazioni, vedere gli articoli di supporto seguenti:

Le condizioni ABAC consentono di filtrare le assegnazioni di ruolo di Entra ID a gruppi e tipi di risorse personalizzate (CRD) specifici, in modo centralizzato, da Microsoft Entra ID, senza scrivere per-cluster RBAC di Kubernetes e manifesti. Per informazioni generali su Azure ABAC, vedere Che cosa sono le condizioni di assegnazione di ruolo di Azure?.

Quando usare le condizioni del controllo degli accessi basato sugli attributi

Usare questa funzionalità quando si vuole:

Limitare i gruppi o i tipi di CRD che un assegnatario può elencare o visualizzare.
Imporre centralmente i confini di accesso alle risorse personalizzati da Microsoft Entra ID senza gestire il controllo degli accessi basato sul ruolo Role e gli oggetti RoleBinding Kubernetes 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:

Attribute	Description
`Microsoft.ContainerService/managedClusters/customResources:group`	Gruppo API della risorsa personalizzata a cui si accede, ad esempio `secrets-store.csi.x-k8s.io`.
`Microsoft.ContainerService/managedClusters/customResources:kind`	Tipo di risorsa personalizzata a cui si accede, ad esempio `secretproviderclasses`.

Aggiungere una condizione ABAC a un'assegnazione di ruolo

L'esempio seguente crea un ruolo personalizzato del lettore CRD di AKS che concede l'accesso in lettura alle risorse personalizzate, quindi lo assegna con una condizione che consenta solo l'accesso a secretproviderclasses nel secrets-store.csi.x-k8s.io gruppo (CRD usato dal provider di Azure Key Vault per il driver CSI dell'archivio segreti).

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>"
    ]
}

Creare la definizione del ruolo usando il az role definition create comando .
```
az role definition create --role-definition @crd-reader.json
```

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'
 )
)

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

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

Dopo la propagazione dell'assegnazione di ruolo (fino a cinque minuti), accedere come la persona assegnata e confermare che può leggere il CRD consentito ma non altri CRD.

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

az aks get-credentials --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME

Elenco secretproviderclasses dal secrets-store.csi.x-k8s.io gruppo 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
```
Elenca authorizationpolicies dal gruppo Istio security.istio.io, bloccato dalla condizione. Il comando dovrebbe fallire con un Forbidden errore dal webhook di autorizzazione Entra ID (presupponendo che il CRD Istio sia installato nel cluster; in caso contrario kubectl restituisce un errore non trovato prima che l'API server raggiunga il webhook di autorizzazione).
```
kubectl get authorizationpolicies.security.istio.io --all-namespaces
```

Pulire le risorse

Disabilitare l'autorizzazione Entra ID

Rimuovere l'autorizzazione Entra ID usando il comando az aks update con il flag --disable-azure-rbac.
```
az aks update --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --disable-azure-rbac
```

Eliminare l'assegnazione di ruolo

Interfaccia della riga di comando di Azure
Portale di Azure

Elencare le assegnazioni di ruolo usando il az role assignment list comando .
```
az role assignment list --scope $AKS_ID --query [].id --output tsv
```
Eliminare le assegnazioni di ruolo usando il az role assignment delete comando .
```
az role assignment delete --ids <LIST OF ASSIGNMENT IDS>
```

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

Interfaccia della riga di comando di Azure
Portale di Azure

Eliminare il gruppo di risorse (e il cluster AKS che contiene) usando il comando az group delete.
```
az group delete --name $RESOURCE_GROUP --yes --no-wait
```

Passaggi successivi

Per ulteriori informazioni sull'autenticazione AKS, l'autorizzazione, il RBAC di Kubernetes e l'RBAC di Azure, vedere:

Commenti e suggerimenti

Questa pagina è stata utile?

Last updated on 2026-04-23