Distribuire e configurare l'Identità del Carico di Lavoro su un cluster AKS abilitato da Azure Arc (anteprima)

Si applica a: AKS locale su Azure

La federazione dell'identità del carico di lavoro consente di configurare un'identità gestita assegnata dall'utente o la registrazione dell'app in Microsoft Entra ID per considerare attendibili i token da un provider di identità esterno (IdP), ad esempio Kubernetes, consentendo l'accesso alle risorse protette da Microsoft Entra, ad esempio Azure Key Vault o Archiviazione BLOB di Azure.

Azure Kubernetes Service (AKS) supportato da Azure Arc è un servizio Kubernetes gestito che consente di effettuare facilmente il deployment di cluster Kubernetes abilitati per l'identità del workload. Questo articolo descrive come eseguire le attività seguenti:

• Creare un cluster AKS Arc con l'identità del carico di lavoro abilitata (anteprima).
• Creare un account del servizio Kubernetes e associarlo all'identità gestita di Azure.
• Creare una credenziale federata nell'identità gestita per considerare attendibile l'emittente OIDC.
• Distribuire l'applicazione.
• Esempio: concedere a un pod nel cluster l'accesso ai segreti in un Azure Key Vault.

Per una panoramica concettuale della federazione delle identità del carico di lavoro, consultare Federazione delle identità del carico di lavoro in Kubernetes abilitato con Azure Arc (anteprima).

Prerequisiti

Prima di distribuire un cluster Kubernetes con Azure Arc abilitato, è necessario disporre dei prerequisiti seguenti:

• Se non hai un abbonamento Azure, crea un account gratuito prima di iniziare.
• Questo articolo richiede la versione 1.4.23 o successiva dell'interfaccia della riga di comando di Azure. Se si usa Azure Cloud Shell, la versione più recente è già installata.

Esportare le variabili di ambiente

Per semplificare la procedura per configurare le identità necessarie, i comandi seguenti definiscono le variabili di ambiente a cui si fa riferimento negli esempi di questo articolo. Sostituire i valori seguenti con valori personalizzati:

$AZSubscriptionID = "00000000-0000-0000-0000-000000000000" 
$Location = "westeurope" 
$resource_group_name = "myResourceGroup" 

$aks_cluster_name = "myAKSCluster" 

$SERVICE_ACCOUNT_NAMESPACE = "default" 
$SERVICE_ACCOUNT_NAME = "workload-identity-sa" 

$FedIdCredentialName = "myFedIdentity" 
$MSIName = "myIdentity" 

# To access key vault secrets from a pod in the cluster, include these variables:
$KVName = "KV-workload-id" 
$KVSecretName= "KV-secret"

Impostare la sottoscrizione attiva

Per prima cosa, configura il tuo abbonamento come quello attivo e corrente. Esegui il comando az account set con il tuo ID sottoscrizione:

az login  
az account set -s $AZSubscriptionID

Creare un gruppo di risorse

Un gruppo di risorse di Azure è un gruppo logico in cui le risorse di Azure vengono distribuite e gestite. Quando si crea un gruppo di risorse, viene richiesto di specificare una posizione. Questa posizione è la posizione di archiviazione dei metadati del gruppo di risorse e dove le risorse vengono eseguite in Azure se non si specifica un'altra regione durante la creazione della risorsa.

Per creare un gruppo di risorse, eseguire il comando az group create:

az group create --name $resource_group_name --location $Location

L'output di esempio seguente mostra la corretta creazione di un gruppo di risorse:

{ 
  "id": "/subscriptions/<guid>/resourceGroups/myResourceGroup", 
  "location": "westeurope", 
  "managedBy": null, 
  "name": "$resource_group_name", 
  "properties": { 
    "provisioningState": "Succeeded" 
  }, 
  "tags": null 
}

Passaggio 1: Creare un cluster Arc AKS con l'identità del carico di lavoro abilitata

Per creare un cluster AKS Arc, sono necessari sia i valori $customlocation_ID sia $logicnet_Id.

• $customlocation_ID: ID di Azure Resource Manager del percorso personalizzato. Il percorso personalizzato viene configurato durante la distribuzione del cluster locale di Azure. L'amministratore dell'infrastruttura deve fornire l'ID del Resource Manager della posizione personalizzata. È anche possibile ottenere l'ID di Resource Manager usando $customlocation_ID = $(az customlocation show --name "<your-custom-location-name>" --resource-group $resource_group_name --query "id" -o tsv), se l'amministratore dell'infrastruttura fornisce un nome di percorso personalizzato e un nome del gruppo di risorse.
• $logicnet_Id: ID di Azure Resource Manager della rete logica locale di Azure creata seguendo questa procedura. L'amministratore dell'infrastruttura deve fornire l'ID di Resource Manager della rete logica. È anche possibile ottenere l'ID di Resource Manager usando $logicnet_Id = $(az stack-hci-vm network lnet show --name "<your-lnet-name>" --resource-group $resource_group_name --query "id" -o tsv), se l'amministratore dell'infrastruttura fornisce un nome di rete logico e un nome del gruppo di risorse.

Eseguire il comando az aksarc create con parametro --enable-oidc-issuer --enable-workload-identity. Specificare entra-admin-group-object-ids e assicurarsi di essere membri del gruppo di amministrazione di Microsoft Entra ID per l'accesso in modalità proxy:

az aksarc create  
-n $aks_cluster_name -g $resource_group_name  
--custom-location $customlocation_ID --vnet-ids $logicnet_Id  
--aad-admin-group-object-ids <entra-admin-group-object-ids> 
--generate-ssh-keys  
--enable-oidc-issuer --enable-workload-identity

Il comando viene completato dopo pochi minuti e vengono restituite informazioni in formato JSON sul cluster.

La distribuzione dell'estensione dell'identità del carico di lavoro potrebbe richiedere del tempo dopo aver creato correttamente un cluster provisionato. Usare il comando seguente per controllare lo stato dell'estensione dell'identità del carico di lavoro:

az connectedk8s show -n $aks_cluster_name -g $resource_group_name

# agentState = "Succeeded" 
"agentPublicKeyCertificate": "", 
  "agentVersion": "1.21.10", 
  "arcAgentProfile": { 
    "agentAutoUpgrade": "Enabled", 
    "agentErrors": [], 
    "agentState": "Succeeded", 
    "desiredAgentVersion": "", 
    "systemComponents": null 

# oidcIssuerProfile "enabled": true and "issuerUrl" present 

"oidcIssuerProfile": { 
    "enabled": true, 
    "issuerUrl": "https://oidcdiscovery-{location}-endpoint-1111111111111111.000.azurefd.net/00000000-0000-0000-0000-000000000000/11111111-1111-1111-1111-111111111111/"}

Nella portale di Azure è possibile visualizzare l'estensione wiextension nella sezione Proprietà del cluster Kubernetes.

Salvare l'URL dell'autorità emittente OIDC in una variabile di ambiente

Dopo aver creato correttamente il cluster AKS, è possibile ottenere l'URL dell'autorità emittente OIDC e salvarlo in una variabile di ambiente. Esegui questo comando:

$SERVICE_ACCOUNT_ISSUER =$(az connectedk8s show --n $aks_cluster_name --resource-group $resource_group_name --query "oidcIssuerProfile.issuerUrl" --output tsv)

Passaggio 2: Creare un account del servizio Kubernetes e associarlo all'identità gestita di Azure

Creare prima di tutto un'identità gestita. Esegui il comando az identity create

az identity create --name $MSIName --resource-group $resource_group_name --location $Location --subscription $AZSubscriptionID

Creare quindi variabili per l'ID client dell'identità gestita:

$MSIId=$(az identity show --resource-group $resource_group_name --name $MSIName --query 'clientId' --output tsv)
$MSIPrincipalId=$(az identity show --resource-group $resource_group_name --name $MSIName --query 'principalId' --output tsv)

Creare un account del servizio Kubernetes

In questo passaggio si crea un account del servizio Kubernetes e lo si annota con l'ID client dell'identità gestita creata nel passaggio precedente.

Usare la connessione del cluster per accedere al cluster da un dispositivo client. Per altre informazioni, vedere Accedere al cluster da un dispositivo client:

az connectedk8s proxy -n $aks_cluster_name -g $resource_group_name

Apri una nuova finestra di comando CLI. Copiare e incollare i comandi seguenti:

$yaml = @"
apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    azure.workload.identity/client-id: $MSIId
  name: $SERVICE_ACCOUNT_NAME
  namespace: $SERVICE_ACCOUNT_NAMESPACE
"@

$yaml = $yaml -replace '\$MSIId', $MSIId `
               -replace '\$SERVICE_ACCOUNT_NAME', $SERVICE_ACCOUNT_NAME `
               -replace '\$SERVICE_ACCOUNT_NAMESPACE', $SERVICE_ACCOUNT_NAMESPACE

$yaml | kubectl apply -f -

L'output seguente mostra la corretta creazione dell'account del servizio:

serviceaccount/workload-identity-sa created

Passaggio 3: Creare una credenziale federata nell'identità gestita per considerare attendibile l'emittente OIDC

Creare prima di tutto una credenziale di identità federata. Chiamare il comando az identity federated-credential create per creare la credenziale di identità federata tra l'identità gestita, l'emittente dell'account di servizio e il soggetto. Per altre informazioni sulle credenziali di identità federate in Microsoft Entra, vedere Panoramica delle credenziali di identità federate in Microsoft Entra ID.

# Create a federated credential 

az identity federated-credential create --name $FedIdCredentialName --identity-name $MSIName --resource-group $resource_group_name --issuer $SERVICE_ACCOUNT_ISSUER --subject "system:serviceaccount:${SERVICE_ACCOUNT_NAMESPACE}:${SERVICE_ACCOUNT_NAME}" 

# Show the federated credential 

az identity federated-credential show --name $FedIdCredentialName --resource-group $resource_group_name --identity-name $MSIName

Passaggio 4: Distribuire l'applicazione

Quando si distribuiscono i pod dell'applicazione, il manifesto deve fare riferimento all'account del servizio creato nel passaggio Creare l'account del servizio Kubernetes. Il manifesto seguente mostra come fare riferimento all'account, in particolare le metadata\namespace proprietà e spec\serviceAccountName . Assicurarsi di specificare un'immagine per image e un nome del contenitore per containerName:

$image = "<image>"  # Replace <image> with the actual image name 
$containerName = "<containerName>"  # Replace <containerName> with the actual container name 

$yaml = @" 
apiVersion: v1 
kind: Pod 
metadata: 
  name: sample-quick-start 
  namespace: $SERVICE_ACCOUNT_NAMESPACE 
  labels: 
    azure.workload.identity/use: "true" # Required. Only pods with this label can use workload identity. 
spec: 
  serviceAccountName: $SERVICE_ACCOUNT_NAME 
  containers: 
    - image: $image 
      name: $containerName 
"@ 

# Replace variables within the YAML content 
$yaml = $yaml -replace '\$SERVICE_ACCOUNT_NAMESPACE', $SERVICE_ACCOUNT_NAMESPACE ` 
                -replace '\$SERVICE_ACCOUNT_NAME', $SERVICE_ACCOUNT_NAME 

# Apply the YAML configuration 
$yaml | kubectl apply -f - 

Esempio: Concedere le autorizzazioni per accedere ad Azure Key Vault

Le istruzioni in questo passaggio descrivono come accedere ai segreti, alle chiavi o ai certificati in un Key Vault di Azure dal pod del cluster. Gli esempi in questa sezione configurano l'accesso ai segreti in Key Vault per l'identità del carico di lavoro, ma è possibile eseguire passaggi simili per configurare l'accesso a chiavi o certificati.

L'esempio seguente illustra come usare il modello di autorizzazione Controllo degli accessi in base al ruolo di Azure per concedere al pod l'accesso a Key Vault. Per altre informazioni sul modello di autorizzazione Controllo degli accessi in base al ruolo di Azure per Azure Key Vault, vedere Concedere alle applicazioni l'autorizzazione per accedere ad Azure Key Vault usando il controllo degli accessi in base al ruolo di Azure.

1. Creare una key vault con protezione dall'eliminazione e autorizzazione RBAC (Controllo degli accessi in base al ruolo) abilitata. È anche possibile usare un'istanza di Key Vault esistente se è configurata sia per la protezione dall'eliminazione permanente che per l'autorizzazione RBAC (Controllo degli accessi in base al ruolo).

   az keyvault create --name $KVName --resource-group $resource_group_name --location $Location --enable-purge-protection --enable-rbac-authorization
   
   # retrieve the key vault ID for role assignment
   $KVId=$(az keyvault show --resource-group $resource_group_name --name $KVName --query id --output tsv)
   

2. Assegna a te stesso il ruolo RBAC di Responsabile dei Segreti del Key Vault in modo da poter creare un segreto nel nuovo key vault. La propagazione delle nuove assegnazioni di ruolo può richiedere fino a cinque minuti, e possono essere aggiornate dal server di autorizzazione.

   $CALLER_OBJECT_ID=$(az ad signed-in-user show --query id -o tsv)
   
   az role assignment create --assignee-object-id $CALLER_OBJECT_ID --role "Key Vault Secrets Officer" --scope $KVId --assignee-principal-type ServicePrincipal
   

3. Creare un segreto in Key Vault:

   az keyvault secret set --vault-name $KVName --name $KVSecretName --value "Hello!"
   

4. Assegnare il ruolo Utente dei segreti di Key Vault all'identità gestita assegnata dall'utente creata in precedenza. Questo passaggio concede all'identità gestita l'autorizzazione per leggere i segreti da Key Vault:

   $IDENTITY_PRINCIPAL_ID=$(az identity show --name "$USER_ASSIGNED_IDENTITY_NAME" --resource-group "$resource_group_name" --query principalId --output tsv)
   
   az role assignment create --assignee-object-id $IDENTITY_PRINCIPAL_ID --role "Key Vault Secrets User" --scope $KVId --assignee-principal-type ServicePrincipal
   

5. Creare una variabile di ambiente per l'URL di Key Vault:

   $KVUrl=$(az keyvault show --resource-group $resource_group_name --name $KVName --query properties.vaultUri --output tsv)
   

6. Distribuire un pod che fa riferimento all'account di servizio e all'URL del Key Vault.

   $yaml = @" 
   apiVersion: v1 
   kind: Pod 
   metadata: 
     name: sample-quick-start 
     namespace: $SERVICE_ACCOUNT_NAMESPACE 
     labels: 
       azure.workload.identity/use: "true" 
   spec: 
     serviceAccountName: $SERVICE_ACCOUNT_NAME 
     containers: 
       - image: ghcr.io/azure/azure-workload-identity/msal-go 
         name: oidc 
         env: 
         - name: KEYVAULT_URL 
           value: $KVUrl 
         - name: SECRET_NAME 
           value: $KVSecretName 
     nodeSelector: 
       kubernetes.io/os: linux 
   "@ 
   
   # Replace variables within the YAML content 
   $yaml = $yaml -replace '\$SERVICE_ACCOUNT_NAMESPACE', $SERVICE_ACCOUNT_NAMESPACE ` 
                   -replace '\$SERVICE_ACCOUNT_NAME', $SERVICE_ACCOUNT_NAME ` 
                   -replace '\$KVUrl', $KVUrl ` 
                   -replace '\$KVSecretName', $KVSecretName 
   
   # Apply the YAML configuration 
   $yaml | kubectl --kubeconfig <path-to-aks-cluster-kubeconfig> apply -f -
   

Eliminare il cluster AKS Arc

Per eliminare il cluster AKS Arc, usare il comando az aksarc delete:

az aksarc delete -n $aks_cluster_name -g $resource_group_name

Passaggi successivi

In questo articolo, hai distribuito e configurato un cluster Kubernetes per utilizzare un'identità del carico di lavoro in preparazione all'autenticazione dei carichi di lavoro dell'applicazione con quella credenziale. A questo punto è possibile distribuire l'applicazione e configurarla per usare l'identità dei carichi di lavoro con la versione più recente della libreria client Identità di Azure.