Distribuire e configurare l'identità del carico di lavoro in un servizio Azure Kubernetes abilitato dal cluster Azure Arc (anteprima)

Articolo
12/20/2024

Si applica a: Locale di Azure, versione 23H2

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.

servizio Azure Kubernetes (servizio Azure Kubernetes) abilitato da Azure Arc è un servizio Kubernetes gestito che consente di distribuire facilmente cluster Kubernetes abilitati per l'identità del carico di lavoro. Questo articolo descrive come eseguire le attività seguenti:

Creare un cluster Arc del servizio Azure Kubernetes 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 insieme di credenziali delle chiavi di Azure.

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

Importante

Queste funzionalità di anteprima sono disponibili in modalità self-service e acconsentono esplicitamente. Le anteprime vengono fornite "così come sono" e "come disponibili" e sono escluse dai contratti di servizio e dalla garanzia limitata. servizio Azure Kubernetes, abilitate dalle anteprime di Azure Arc, sono parzialmente coperte dal supporto tecnico per il massimo sforzo.

Nota

Nell'anteprima pubblica, AKS su Azure Locale, versione 23H2, supporta l'abilitazione dell'identità del carico di lavoro durante la creazione del cluster AKS. Tuttavia, l'abilitazione dell'identità del carico di lavoro dopo la creazione del cluster o la disabilitazione successiva non è attualmente supportata.

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

Prima di tutto, impostare la sottoscrizione come sottoscrizione attiva corrente. Eseguire il comando az account set con l'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 del servizio Azure Kubernetes con l'identità del carico di lavoro abilitata

Per creare un cluster Arc del servizio Azure Kubernetes, sono necessari sia i $customlocation_ID valori e $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, versione 23H2. L'amministratore dell'infrastruttura deve fornire l'ID 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 il --enable-oidc-issuer --enable-workload-identity parametro . 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 di cui è stato effettuato il provisioning. 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.

Importante

Nell'ambito del miglioramento della sicurezza per i cluster Arc del servizio Azure Kubernetes, l'abilitazione dell'identità del carico di lavoro attiva due modifiche. Prima di tutto, la chiave di firma dell'account del servizio Kubernetes ruota automaticamente ogni 45 giorni e rimane valida per 90 giorni. In secondo luogo, il --service-account-extend-token-expiration flag è disabilitato, riducendo la validità del token da un anno a un massimo di 24 ore.

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

Dopo aver creato correttamente il cluster del servizio Azure Kubernetes, è 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. Eseguire 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

Creare un account del servizio Kubernetes e annotarlo con l'ID client dell'identità gestita creata nel passaggio precedente:

az connectedk8s proxy -n $aks_cluster_name -g $resource_group_name

Aprire una nuova finestra. Copiare e incollare i comandi dell'interfaccia della riga di comando 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 le credenziali di identità federata tra l'identità gestita, l'autorità di certificazione dell'account del servizio e l'oggetto. 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

Nota

Dopo aver aggiunto una credenziale di identità federata, la propagazione richiede alcuni secondi. Le richieste di token effettuate immediatamente dopo potrebbero non riuscire finché la cache non viene aggiornata. Per evitare questo problema, prendere in considerazione l'aggiunta di un breve ritardo dopo la creazione delle credenziali dell'identità federata.

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 -

Importante

Assicurarsi che i pod dell'applicazione che usano l'identità del carico di lavoro includano l'etichetta azure.workload.identity/use: "true" nella specifica del pod. In caso contrario, i pod avranno esito negativo dopo il riavvio.

Esempio: Concedere le autorizzazioni per accedere ad Azure Key Vault

Le istruzioni in questo passaggio descrivono come accedere a segreti, chiavi o certificati in un insieme di credenziali delle chiavi di Azure dal pod. 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.

Creare un'istanza di Key Vault con la protezione dall'eliminazione e l'autorizzazione di 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 che per l'autorizzazione di 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)
```
Assegnare il ruolo Di responsabile dei segreti dell'insieme di credenziali delle chiavi di Controllo degli accessi in base al ruolo a se stessi in modo da poter creare un segreto nel nuovo insieme di credenziali delle chiavi. La propagazione delle nuove assegnazioni di ruolo può richiedere fino a cinque minuti, e possono essere aggiornate dal server di autorizzazione.
```
az role assignment create --assignee-object-id $MSIPrincipalId --role "Key Vault Secrets Officer" --scope $KVId --assignee-principal-type ServicePrincipal
```

Creare un segreto in Key Vault:

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

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:
```
az role assignment create --assignee-object-id $MSIPrincipalId --role "Key Vault Secrets User" --scope $KVId --assignee-principal-type ServicePrincipal
```

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)

Distribuire un pod che fa riferimento all'account del servizio e all'URL di 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

Nota

Si è verificato un problema noto durante l'eliminazione di un cluster AKS Arc con risorse PodDisruptionBudget (PDB): l'eliminazione potrebbe non riuscire a rimuovere queste risorse PDB. Microsoft è a conoscenza del problema e sta lavorando a una correzione.

PDB viene installato per impostazione predefinita nei cluster AKS Arc abilitati per l'identità del carico di lavoro. Per eliminare un cluster AKS Arc con identità del carico di lavoro abilitata, vedere la guida alla risoluzione dei problemi .

Passaggi successivi

In questo articolo è stato distribuito e configurato un cluster Kubernetes per l'uso di un'identità dei carichi di lavoro in preparazione per l'autenticazione dei carichi di lavoro dell'applicazione con tale 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.

Condividi tramite

Distribuire e configurare l'identità del carico di lavoro in un servizio Azure Kubernetes abilitato dal cluster Azure Arc (anteprima)

Prerequisiti

Esportare le variabili di ambiente

Impostare la sottoscrizione attiva

Creare un gruppo di risorse

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

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

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

Creare un account del servizio Kubernetes

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

Passaggio 4: Distribuire l'applicazione

Esempio: Concedere le autorizzazioni per accedere ad Azure Key Vault

Eliminare il cluster AKS Arc

Passaggi successivi

Commenti e suggerimenti

Risorse aggiuntive