Share via


Distribuire e configurare l'identità dei carichi di lavoro in un cluster del servizio Azure Kubernetes

Il servizio Azure Kubernetes è un servizio Kubernetes gestito che permette di distribuire e gestire rapidamente i cluster Kubernetes. Contenuto dell'articolo:

  • Distribuire un cluster del servizio Azure Kubernetes usando l'interfaccia della riga di comando di Azure che include l'autorità di certificazione OpenID Connect e un ID dei carichi di lavoro di Microsoft Entra
  • Concedere l'accesso ad Azure Key Vault
  • Creare un ID dei carichi di lavoro di Microsoft Entra e un account del servizio Kubernetes.
  • Configurare l'identità gestita per la federazione dei token.

Questo articolo presuppone che si abbia una conoscenza di base dei concetti relativi a Kubernetes. Per altre informazioni, vedere Concetti di base relativi a Kubernetes per il servizio Azure Kubernetes. Se non si ha familiarità con l'ID dei carichi di lavoro di Microsoft Entra, vedere l'articolo Panoramica seguente.

  • Questo articolo richiede la versione 2.47.0 o successiva dell'interfaccia della riga di comando di Azure. Se si usa Azure Cloud Shell, la versione più recente è già installata.

  • L'identità usata per creare il cluster ha le autorizzazioni minime adeguate. Per altre informazioni sull'accesso e l'identità per il servizio Azure Kubernetes, vedere Opzioni di accesso e identità per il servizio Azure Kubernetes (AKS).

  • Se si hanno più sottoscrizioni di Azure, selezionare l'ID sottoscrizione appropriato in cui devono essere fatturate le risorse, usando il comando account az.

Nota

Invece di configurare manualmente tutti i passaggi, esiste un'altra implementazione denominata Service Connessione or che consente di configurare automaticamente alcuni passaggi e ottenere lo stesso risultato. Vedere anche: Esercitazione: Connessione all'account di archiviazione di Azure in servizio Azure Kubernetes (AKS) con Service Connessione or usando l'identità del carico di lavoro.

Esportare le variabili di ambiente

Per semplificare la procedura per configurare le identità necessarie, la procedura seguente definisce le variabili di ambiente per riferimento nel cluster.

Eseguire i comandi seguenti per creare queste variabili. Sostituire i valori predefiniti per RESOURCE_GROUP, LOCATION, SERVICE_ACCOUNT_NAME, SUBSCRIPTION, USER_ASSIGNED_IDENTITY_NAME e FEDERATED_IDENTITY_CREDENTIAL_NAME.

export RESOURCE_GROUP="myResourceGroup"
export LOCATION="westcentralus"
export SERVICE_ACCOUNT_NAMESPACE="default"
export SERVICE_ACCOUNT_NAME="workload-identity-sa"
export SUBSCRIPTION="$(az account show --query id --output tsv)"
export USER_ASSIGNED_IDENTITY_NAME="myIdentity"
export FEDERATED_IDENTITY_CREDENTIAL_NAME="myFedIdentity"

Creare un cluster del servizio Azure Container

Creare un cluster del servizio Azure Kubernetes usando il comando az aks create con il parametro --enable-oidc-issuer per usare l'autorità di certificazione OIDC. L'esempio seguente crea un cluster denominato myAKSCluster con un nodo in myResourceGroup:

az aks create --resource-group "${RESOURCE_GROUP}" --name myAKSCluster --enable-oidc-issuer --enable-workload-identity --generate-ssh-keys

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

Nota

Quando si crea un cluster del servizio Azure Kubernetes, viene creato automaticamente un secondo gruppo di risorse per archiviare le risorse del servizio Azure Kubernetes. Per altre informazioni, vedere Perché vengono creati due gruppi di risorse con servizio Azure Kubernetes?.

Aggiornare un cluster del servizio Azure Kubernetes esistente

È possibile aggiornare un cluster del servizio Azure Kubernetes usando il comando az aks update con --enable-oidc-issuer e il parametro --enable-workload-identity per usare l'autorità emittente OIDC e abilitare l'identità dei carichi di lavoro. L'esempio seguente aggiorna un cluster chiamato myAKSCluster:

az aks update --resource-group "${RESOURCE_GROUP}" --name myAKSCluster --enable-oidc-issuer --enable-workload-identity

Recuperare l'URL dell'autorità di certificazione OIDC

Per ottenere l'URL dell'autorità emittente OIDC e salvarlo in una variabile di ambiente, eseguire il comando seguente. Sostituire il valore predefinito per gli argomenti --name, ovvero il nome del cluster:

export AKS_OIDC_ISSUER="$(az aks show --name myAKSCluster --resource-group "${RESOURCE_GROUP}" --query "oidcIssuerProfile.issuerUrl" -o tsv)"

La variabile deve contenere l'URL dell'autorità di certificazione simile all'esempio seguente:

https://eastus.oic.prod-aks.azure.com/00000000-0000-0000-0000-000000000000/11111111-1111-1111-1111-111111111111/

Per impostazione predefinita, l'autorità di certificazione è impostata per usare l'URL di base https://{region}.oic.prod-aks.azure.com/{tenant_id}/{uuid}, dove il valore per {region} corrisponde al luogo dove viene distribuito il cluster del servizio Azure Kubernetes. Il valore {uuid} rappresenta la chiave OIDC.

Creare un'identità gestita

Usare il comando az account set dell'interfaccia della riga di comando di Azure per impostare una sottoscrizione specifica come sottoscrizione attiva corrente. Quindi, usare il comando az identity create per creare un'identità gestita.

az identity create --name "${USER_ASSIGNED_IDENTITY_NAME}" --resource-group "${RESOURCE_GROUP}" --location "${LOCATION}" --subscription "${SUBSCRIPTION}"

Creare quindi una variabile per l'ID identità gestita.

export USER_ASSIGNED_CLIENT_ID="$(az identity show --resource-group "${RESOURCE_GROUP}" --name "${USER_ASSIGNED_IDENTITY_NAME}" --query 'clientId' -o 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. Usare il comando az aks get-credentials e sostituire i valori del nome del cluster e il nome del gruppo di risorse.

az aks get-credentials --name myAKSCluster --resource-group "${RESOURCE_GROUP}"

Copiare e incollare il seguente input su più righe nell'interfaccia della riga di comando di Azure.

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    azure.workload.identity/client-id: "${USER_ASSIGNED_CLIENT_ID}"
  name: "${SERVICE_ACCOUNT_NAME}"
  namespace: "${SERVICE_ACCOUNT_NAMESPACE}"
EOF

L'output seguente è simile alla corretta creazione dell'identità:

serviceaccount/workload-identity-sa created

Stabilire credenziali di identità federate

Usare il comando az identity federated-credential create per creare le credenziali di identità federate tra l'identità gestita, l'autorità di certificazione dell'account del servizio e l'oggetto.

az identity federated-credential create --name ${FEDERATED_IDENTITY_CREDENTIAL_NAME} --identity-name "${USER_ASSIGNED_IDENTITY_NAME}" --resource-group "${RESOURCE_GROUP}" --issuer "${AKS_OIDC_ISSUER}" --subject system:serviceaccount:"${SERVICE_ACCOUNT_NAMESPACE}":"${SERVICE_ACCOUNT_NAME}" --audience api://AzureADTokenExchange

Nota

La propagazione delle credenziali di identità federata dopo l'aggiunta iniziale richiede alcuni secondi. Se una richiesta di token viene creata immediatamente dopo l'aggiunta delle credenziali dell'identità federata, è possibile che si verifichi un errore per un paio di minuti, perché la cache viene popolata nella directory con dati obsoleti. Per evitare questo problema, è possibile aggiungere un lieve ritardo dopo l'aggiunta delle credenziali di identità federate.

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 illustra come fare riferimento all'account, in particolare alle proprietà metadata\namespace e spec\serviceAccountName:

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: your-pod
  namespace: "${SERVICE_ACCOUNT_NAMESPACE}"
  labels:
    azure.workload.identity/use: "true"  # Required, only the pods with this label can use workload identity
spec:
  serviceAccountName: "${SERVICE_ACCOUNT_NAME}"
  containers:
    - image: <your image>
      name: <containerName>
EOF

Importante

Assicurarsi che i pod dell'applicazione che usano l'identità dei carichi di lavoro abbiano aggiunto l'etichetta azure.workload.identity/use: "true" seguente alla specifica del pod. In caso contrario, i pod avranno esito negativo dopo il riavvio.

Facoltativo: concedere le autorizzazioni per accedere ad Azure Key Vault

Questo passaggio è necessario se occorre accedere a segreti, chiavi e certificati montati in Azure Key Vault da un pod. Per configurare l'accesso con un'identità gestita, seguire questa procedura. Questi passaggi presuppongono che un'istanza di Azure Key Vault sia già stata creata e configurata nella sottoscrizione. Se non è disponibile alcuna istanza, vedere Creare un'istanza di Azure Key Vault usando l'interfaccia della riga di comando di Azure.

Prima di procedere, sono necessarie le informazioni seguenti:

  • Nome dell'insieme di credenziali delle chiavi
  • Gruppo di risorse che contiene l'insieme di credenziali delle chiavi

È possibile recuperare queste informazioni usando il comando seguente dell'interfaccia della riga di comando di Azure: az keyvault list.

  1. Impostare un criterio di accesso per l'identità gestita per accedere ai segreti nell'insieme di credenziali delle chiavi eseguendo i comandi seguenti:

    export KEYVAULT_RESOURCE_GROUP="myResourceGroup"
    export KEYVAULT_NAME="myKeyVault"
    export USER_ASSIGNED_CLIENT_ID="$(az identity show --resource-group "${RESOURCE_GROUP}" --name "${USER_ASSIGNED_IDENTITY_NAME}" --query 'clientId' -o tsv)"
    
    az keyvault set-policy --name "${KEYVAULT_NAME}" --secret-permissions get --spn "${USER_ASSIGNED_CLIENT_ID}"
    
  2. Creare un segreto nell'insieme di credenziali delle chiavi:

    export KEYVAULT_SECRET_NAME="my-secret"
    
    az keyvault secret set --vault-name "${KEYVAULT_NAME}" \
       --name "${KEYVAULT_SECRET_NAME}" \
       --value "Hello\!"
    
  3. Esportare l'URL dell'insieme di credenziali delle chiavi:

    export KEYVAULT_URL="$(az keyvault show --resource-group ${KEYVAULT_RESOURCE_GROUP} --name ${KEYVAULT_NAME} --query properties.vaultUri -o tsv)"
    
  4. Distribuire un pod che fa riferimento all'account del servizio e all'URL dell'insieme di credenziali delle chiavi precedente:

    cat <<EOF | kubectl apply -f -
    apiVersion: v1
    kind: Pod
    metadata:
      name: 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: ${KEYVAULT_URL}
          - name: SECRET_NAME
            value: ${KEYVAULT_SECRET_NAME}
      nodeSelector:
        kubernetes.io/os: linux
    EOF
    

Per verificare se tutte le proprietà vengono inserite correttamente dal webhook, usare il comando kubectl describe:

kubectl describe pod quick-start | grep "SECRET_NAME:"

In caso di esito positivo, l'output dovrebbe essere simile al seguente:

      SECRET_NAME:                 ${KEYVAULT_SECRET_NAME}

Per verificare che il pod sia in grado di ottenere un token e accedere alla risorsa, usare il comando kubectl logs:

kubectl logs quick-start

In caso di esito positivo, l'output dovrebbe essere simile al seguente:

I0114 10:35:09.795900       1 main.go:63] "successfully got secret" secret="Hello\\!"

Disabilitare l'identità dei carichi di lavoro

Per disabilitare l'ID dei carichi di lavoro di Microsoft Entra nel cluster servizio Azure Kubernetes in cui è stato abilitato e configurato, è possibile eseguire il comando seguente:

az aks update --resource-group "${RESOURCE_GROUP}" --name myAKSCluster --disable-workload-identity

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. Se non è possibile riscrivere l'applicazione per usare la versione più recente della libreria client, è possibile configurare il pod dell'applicazione per eseguire l'autenticazione usando l'identità gestita con l'identità dei carichi di lavoro come soluzione di migrazione a breve termine.