Configurare le associazioni di identità nel servizio Azure Kubernetes (anteprima)

Configurare le associazioni di identità nei cluster di Azure Kubernetes Service per mappare un'identità gestita assegnata dall'utente (UAMI) in più cluster usando una singola credenziale FIC (Federated Identity Credential). Questa configurazione consente di ridimensionare l'autenticazione di Microsoft Entra per i carichi di lavoro senza raggiungere i limiti FIC.

Prerequisiti

Installare o aggiornare l'estensione aks-preview

  • Installare o aggiornare l'estensione del CLI di Azure aks-preview all'ultima versione utilizzando il comando az extension add o az extension update.

    # Install the aks-preview extension
az extension add --name aks-preview

# Update to the latest version if already installed
az extension update --name aks-preview

Abilitare il flag di funzionalità IdentityBindingPreview

  1. Registrare il flag di funzionalità IdentityBindingPreview nella sottoscrizione di Azure con il comando az feature register.

    az feature register --namespace Microsoft.ContainerService --name IdentityBindingPreview

    Il completamento della registrazione delle funzionalità può richiedere fino a 15 minuti.

  2. Attendere il completamento della registrazione della funzionalità usando il az feature show comando .

    az feature show --namespace Microsoft.ContainerService --name IdentityBindingPreview

  3. Quando la funzionalità appare come Registered, aggiorna la registrazione del provider usando il comando az provider register.

    az provider register --namespace Microsoft.ContainerService

Limitazioni

Creare risorse di test

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

    export RESOURCE_GROUP="ib-test"
export LOCATION="westus2"

az group create --name $RESOURCE_GROUP --location $LOCATION

  2. Creare un cluster del servizio Azure Kubernetes con l'identità dei carichi di lavoro e l'autorità emittente OIDC abilitata con il comando az aks create con i flag --enable-workload-identity e --enable-oidc-issuer.

    export CLUSTER_NAME="ib-test-cluster"

az aks create --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --location $LOCATION --no-ssh-key --enable-workload-identity --enable-oidc-issuer

  3. Creare un'Identità Gestita Assegnata dall'Utente usando il comando az identity create.

    export MI_NAME="ib-test-mi"
az identity create --resource-group $RESOURCE_GROUP --name $MI_NAME

Verificare la versione del webhook per l'identità dei carichi di lavoro

  • L'associazione di identità richiede la versione di anteprima del webhook per l'identità dei carichi di lavoro. Verificare la versione del webhook installato usando il comando seguente kubectl get pods :

    kubectl -n kube-system get pods -l azure-workload-identity.io/system=true -o yaml | grep v1.6.0

    L'output dovrebbe mostrare v1.6.0-alpha.1 nel tag immagine, confermando l'installazione della versione corretta.

Ottenere gli ID UAMI

  • Ottieni gli ID risorsa, principale, client e tenant di UAMI e impostali come variabili di ambiente usando i seguenti comandi az identity show:

    export MI_RESOURCE_ID=$(az identity show --resource-group $RESOURCE_GROUP --name $MI_NAME --query id --output tsv)
export MI_PRINCIPAL_ID=$(az identity show --resource-group $RESOURCE_GROUP --name $MI_NAME --query principalId --output tsv)
export MI_CLIENT_ID=$(az identity show --resource-group $RESOURCE_GROUP --name $MI_NAME --query clientId --output tsv)
export MI_TENANT_ID=$(az identity show --resource-group $RESOURCE_GROUP --name $MI_NAME --query tenantId --output tsv)

Creare un collegamento d'identità

  • Eseguire il mapping dell'identità gestita assegnata dall'utente al cluster del servizio Kubernetes con un'associazione di identità usando il comando az aks identity-binding create.

    az aks identity-binding create --resource-group $RESOURCE_GROUP --cluster-name $CLUSTER_NAME --name "${MI_NAME}-ib" --managed-identity-resource-id $MI_RESOURCE_ID

    Annotazioni

    Quando si crea un'associazione di identità, il servizio Azure Kubernetes crea automaticamente una credenziale di identità federata denominata aks-identity-binding nell'identità gestita assegnata dall'utente. Questa credenziale è gestita da AKS (Azure Kubernetes Service). Non modificarlo o eliminarlo mentre le associazioni di identità sono in uso. Il FIC creato per i binding di identità viene condiviso da tutti i binding di identità che fanno riferimento allo stesso UAMI.

Ottieni l'URL dell'autorità emittente OIDC per UAMI

  • Ottenere l'URL dell'emittente OIDC associato all'UAMI esaminando l'associazione di identità usando il comando az aks identity-binding show.

    az aks identity-binding show --resource-group $RESOURCE_GROUP --cluster-name $CLUSTER_NAME --name "${MI_NAME}-ib"

    Output di esempio condensato:

    {
  "oidcIssuer": {
    "oidcIssuerUrl": "https://ib.oic.prod-aks.azure.com/<MI-tenant-id>/<MI-client-id>"
  }
}

Connettersi al cluster AKS

  1. Ottenere le credenziali del cluster del servizio Azure Kubernetes usando il az aks get-credentials comando e salvarle in un file kubeconfig separato:

    az aks get-credentials --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME -a -f "${CLUSTER_NAME}.kubeconfig"

  2. Impostare la KUBECONFIG variabile di ambiente in modo che punti al nuovo file kubeconfig:

    export KUBECONFIG="$(pwd)/${CLUSTER_NAME}.kubeconfig"

Autorizzare namespace e account di servizio

  • Configurare il controllo degli accessi in base al ruolo per concedere a soggetti specifici l'autorizzazione a usare l'identità gestita tramite l'associazione di identità, applicando il file manifesto seguente con il comando kubectl apply.

    Annotazioni

    L'esempio seguente fa riferimento in modo esplicito all'account di servizio demo nello spazio dei nomi demo. Anche se fare esplicito riferimento a un account di servizio specifico è un'opzione, è anche possibile riferirsi a una raccolta di account di servizio sotto subjects. Per altre informazioni, vedere Riferimenti a soggetti nella documentazione di Kubernetes.

    kubectl apply -f - <<EOF
apiVersion: v1
kind: Namespace
metadata:
  name: demo
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: demo
  namespace: demo
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: use-mi-${MI_CLIENT_ID}
rules:
  - verbs: ["use-managed-identity"]
    apiGroups: ["cid.wi.aks.azure.com"]
    resources: ["${MI_CLIENT_ID}"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: use-mi-${MI_CLIENT_ID}
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: use-mi-${MI_CLIENT_ID}
subjects:
  - kind: ServiceAccount
    name: demo
    namespace: demo
EOF

Creare un Key Vault di Azure con protezione dalla cancellazione e autorizzazione tramite Azure RBAC

  • Creare un insieme di credenziali delle chiavi con protezione dall'eliminazione e autorizzazione di Controllo degli accessi in base al ruolo di Azure abilitata con il comando az keyvault create e con i flag --enable-purge-protection e --enable-rbac-authorization. È anche possibile usare un key vault esistente se è configurato sia per la protezione dalla rimozione che per l'autorizzazione di Azure RBAC.

    export KEY_VAULT_NAME="ib-test"

az keyvault create \
    --name $KEY_VAULT_NAME \
    --resource-group $RESOURCE_GROUP \
    --location $LOCATION \
    --enable-purge-protection \
    --enable-rbac-authorization

Ottenere l'ID risorsa e l'URL dell'insieme di credenziali delle chiavi

  1. Ottenere il resource ID del Key Vault usando il comando az keyvault show e impostarlo come variabile di ambiente:

    export KEY_VAULT_RESOURCE_ID=$(az keyvault show --resource-group $RESOURCE_GROUP \
    --name $KEY_VAULT_NAME \
    --query id \
    --output tsv)

  2. Ottenere l'URL del Key Vault usando il comando az keyvault show e impostarlo come variabile di ambiente.

    export KEYVAULT_URL="$(az keyvault show \
    --resource-group $RESOURCE_GROUP \
    --name $KEY_VAULT_NAME \
    --query properties.vaultUri \
    --output tsv)"

Configurare l'accesso al Key Vault e creare un segreto

I passaggi seguenti illustrano come accedere a segreti, chiavi o certificati in Azure Key Vault 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 RBAC di Azure per concedere al pod l'accesso al Key Vault. Per ulteriori informazioni sul modello di autorizzazione RBAC di Azure per Azure Key Vault, vedere Concedere l'autorizzazione alle applicazioni per accedere ad Azure Key Vault usando Azure RBAC.

  1. Ottenere l'ID oggetto dell'utente connesso usando il az ad signed-in-user show comando e impostarlo come variabile di ambiente:

    export CALLER_OBJECT_ID=$(az ad signed-in-user show --query id --output tsv)

  2. Assegnare a se stessi il ruolo di Controllo degli accessi in base al ruolo di Azure Responsabile dei segreti di Key Vault nell'insieme di credenziali delle chiavi con il comando az role assignment create.

    az role assignment create --assignee $CALLER_OBJECT_ID \
    --role "Key Vault Secrets Officer" \
    --scope $KEY_VAULT_RESOURCE_ID

  3. Creare un segreto nell'insieme di credenziali delle chiavi usando il comando az keyvault secret set.

    export KEY_VAULT_SECRET_NAME="my-secret"

az keyvault secret set \
    --vault-name $KEY_VAULT_NAME \
    --name $KEY_VAULT_SECRET_NAME \
    --value "Hello\!"

  4. Assegnare il ruolo Key Vault Secrets User all'UAMI usando il comando az role assignment create.

    az role assignment create \
    --assignee-object-id $MI_PRINCIPAL_ID \
    --role "Key Vault Secrets User" \
    --scope $KEY_VAULT_RESOURCE_ID \
    --assignee-principal-type ServicePrincipal

Annotare l'account del servizio

  1. Annotare l'account di servizio con l'ID tenant dell'identità gestita usando il comando kubectl annotate.

    kubectl annotate sa demo -n demo azure.workload.identity/tenant-id=$MI_TENANT_ID

  2. Annotare l'account di servizio con l'ID client dell'identità gestita usando il comando kubectl annotate.

    kubectl annotate sa demo -n demo azure.workload.identity/client-id=$MI_CLIENT_ID

Distribuire l'applicazione di esempio

  • Distribuire il pod di esempio che usa l'associazione di identità per ottenere un token di accesso per l'identità gestita per accedere ad Azure Key Vault usando il comando seguente kubectl apply :

    kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: demo
  namespace: demo
  labels:
    azure.workload.identity/use: "true"
  annotations:
    azure.workload.identity/use-identity-binding: "true"
spec:
  serviceAccount: demo
  containers:
    - name: azure-sdk
      # source code: https://github.com/Azure/azure-workload-identity/blob/feature/custom-token-endpoint/examples/identitybinding-msal-go/main.go
      image: ghcr.io/bahe-msft/azure-workload-identity/identitybinding-msal-go:latest-linux-amd64
      env:
        - name: KEYVAULT_URL
          value: ${KEYVAULT_URL}
        - name: SECRET_NAME
          value: ${KEY_VAULT_SECRET_NAME}
  restartPolicy: Never
EOF

Verificare l'accesso al Key Vault dall'applicazione di esempio

  1. Descrivere il pod e verificare che le variabili di ambiente e i montaggi dei volumi di token previsti siano presenti usando il comando kubectl describe pod.

    kubectl describe pod demo -n demo

    L'output previsto deve contenere valori per AZURE_CLIENT_ID, AZURE_TENANT_IDAZURE_FEDERATED_TOKEN_FILE, , AZURE_AUTHORITY_HOST, AZURE_KUBERNETES_TOKEN_PROXY. AZURE_KUBERNETES_SNI_NAME e AZURE_KUBERNETES_CA_FILE.

  2. Verificare che il pod possa ottenere un token e accedere alla risorsa usando il kubectl logs comando .

    kubectl logs demo -n demo

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

    I1107 20:03:42.865180       1 main.go:77] "successfully got secret" secret="Hello!"

Scalare le associazioni di identità tra più cluster

I binding di identità consentono di mappare più cluster del servizio Azure Kubernetes (AKS) allo stesso UAMI mentre si utilizza ancora un singolo FIC. Per ridimensionare le associazioni di identità tra più cluster, è possibile ripetere i passaggi da Creare un'associazione di identità fino a Verificare l'accesso a Key Vault dall'applicazione di esempio per ogni cluster aggiuntivo che si desidera mappare allo stesso UAMI (creando un nuovo binding di identità per ciascun cluster).

Pulire le risorse

Se non sono più necessarie le risorse create in questo articolo, è possibile pulirle per evitare di incorrere in costi futuri.

  1. Eliminare il pod usando il comando kubectl delete pod.

    kubectl delete pod demo -n demo

  2. Eliminare il namespace usando il comando kubectl delete ns.

    kubectl delete ns demo

  3. Eliminare il gruppo di risorse e tutte le risorse correlate usando il az group delete comando .

    az group delete --name $RESOURCE_GROUP --yes --no-wait

Contenuti correlati

  • Last updated on