Microsoft Entra-workload-id implementeren en configureren op een AKS-cluster (Azure Kubernetes Service)

In dit artikel leert u hoe u een AKS-cluster (Azure Kubernetes Service) implementeert en configureert met de Workload-id van Microsoft Entra. De stappen in dit artikel zijn onder andere:

• Maak een nieuw AKS-cluster of werk een bestaand AKS-cluster bij met behulp van de Azure CLI met OIDC-verlener (OpenID Connect) en microsoft Entra Workload ID ingeschakeld.
• Maak een workload-identiteit en een Kubernetes-serviceaccount.
• Configureer de beheerde identiteit voor tokenfederatie.
• Implementeer de workload en controleer de verificatie met de workload-id.
• U kunt desgewenst een pod in het cluster toegang verlenen tot geheimen in een Azure-sleutelkluis.

Vereisten

• Als u geen Azure-account hebt, maak dan een gratis account aan voordat u begint.
• Voor dit artikel is versie 2.47.0 of hoger van de Azure CLI vereist. Als u Azure Cloud Shell gebruikt, is de nieuwste versie al geïnstalleerd.
• Zorg ervoor dat de identiteit die u gebruikt om uw cluster te maken over de juiste minimale machtigingen beschikt. Zie Toegangs- en identiteitsopties voor Azure Kubernetes Service (AKS) voor meer informatie.
• Als u meerdere Azure-abonnementen hebt, selecteert u de juiste abonnements-id waarin de resources moeten worden gefactureerd met behulp van de az account set opdracht.

Een brongroep maken

• Maak een resourcegroep met behulp van de az group create opdracht.

  export RANDOM_ID="$(openssl rand -hex 3)"
  export RESOURCE_GROUP="myResourceGroup$RANDOM_ID"
  export LOCATION="<your-preferred-region>"
  az group create --name "${RESOURCE_GROUP}" --location "${LOCATION}"
  

OIDC-uitgever en Microsoft Entra Workload ID inschakelen op een AKS-cluster

U kunt OIDC-verlener en Microsoft Entra Workload-id inschakelen op een nieuw of bestaand AKS-cluster.

De URL van de OIDC-verlener ophalen

• Haal de URL van de OIDC-verlener op en sla deze op in een omgevingsvariabele met behulp van de opdracht [az aks show][az-aks-show].

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

  De omgevingsvariabele moet de URL van de verlener bevatten, vergelijkbaar met het volgende voorbeeld:

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

  De verlener is standaard ingesteld op het gebruik van de basis-URL https://{region}.oic.prod-aks.azure.com/{tenant_id}/{uuid}, waarbij de waarde voor {region} de locatie waarop het AKS-cluster wordt geïmplementeerd, overeenkomt met de locatie. De waarde {uuid} vertegenwoordigt de OIDC-sleutel, een willekeurig gegenereerde en onveranderbare GUID voor elk cluster.

Een beheerde identiteit maken

1. Haal uw abonnements-id op en sla deze op in een omgevingsvariabele met behulp van de opdracht [az account show][az-account-show].

   export SUBSCRIPTION="$(az account show --query id --output tsv)"
   

2. Maak een door de gebruiker toegewezen beheerde identiteit met behulp van de az identity create opdracht.

   export USER_ASSIGNED_IDENTITY_NAME="myIdentity$RANDOM_ID"
   az identity create \
       --name "${USER_ASSIGNED_IDENTITY_NAME}" \
       --resource-group "${RESOURCE_GROUP}" \
       --location "${LOCATION}" \
       --subscription "${SUBSCRIPTION}"
   

   In het volgende uitvoervoorbeeld ziet u hoe een beheerde identiteit is gemaakt:

   {
     "clientId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
     "id": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourcegroups/myResourceGroupxxxxxx/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myIdentityxxxxxx",
     "location": "eastus",
     "name": "myIdentityxxxxxx",
     "principalId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
     "resourceGroup": "myResourceGroupxxxxxx",
     "systemData": null,
     "tags": {},
     "tenantId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
     "type": "Microsoft.ManagedIdentity/userAssignedIdentities"
   }
   

3. Haal de client-id van de beheerde identiteit op en sla deze op in een omgevingsvariabele met behulp van de opdracht [az identity show][az-identity-show].

   export USER_ASSIGNED_CLIENT_ID="$(az identity show \
       --resource-group "${RESOURCE_GROUP}" \
       --name "${USER_ASSIGNED_IDENTITY_NAME}" \
       --query 'clientId' \
       --output tsv)"
   

Een Kubernetes-serviceaccount maken

1. Maak verbinding met uw AKS-cluster met behulp van de az aks get-credentials opdracht.

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

2. Maak een Kubernetes-serviceaccount en annotaeer dit met de client-id van de beheerde identiteit door het volgende manifest toe te passen met behulp van de kubectl apply opdracht:

   export SERVICE_ACCOUNT_NAME="workload-identity-sa$RANDOM_ID"
   export SERVICE_ACCOUNT_NAMESPACE="default"
   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
   

   In de volgende uitvoer ziet u dat de workloadidentiteit is gemaakt:

   serviceaccount/workload-identity-sa created
   

De federatieve identiteitsreferentie maken

• Maak een federatieve identiteitsreferentie tussen de beheerde identiteit, de verlener van het serviceaccount en het onderwerp met behulp van de az identity federated-credential create opdracht.

  export FEDERATED_IDENTITY_CREDENTIAL_NAME="myFedIdentity$RANDOM_ID"
  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
  

  Notitie

  Het duurt enkele seconden voordat een federatieve identiteitsreferentie zich heeft verspreid nadat deze is toegevoegd. Als er direct na het toevoegen van de federatieve identiteitsreferentie een tokenaanvraag wordt gedaan, mislukt de aanvraag mogelijk totdat de cache wordt vernieuwd. U kunt dit probleem voorkomen door een kleine vertraging toe te voegen nadat u de federatieve identiteitsreferentie hebt toegevoegd.

Zie Overzicht van federatieve identiteitsreferenties in Microsoft Entra voor meer informatie over federatieve identiteitsreferenties in Microsoft Entra-id.

Een sleutelkluis maken met Azure RBAC-autorisatie

In het volgende voorbeeld ziet u hoe u het machtigingsmodel voor op rollen gebaseerd toegangsbeheer (Azure RBAC) van Azure gebruikt om de pod toegang te verlenen tot de sleutelkluis. Zie Machtiging verlenen aan toepassingen voor toegang tot een Azure-sleutelkluis met behulp van Azure RBAC voor meer informatie over het Azure RBAC-machtigingsmodel voor Azure Key Vault.

1. Maak een sleutelkluis met opschoningsbeveiliging en Azure RBAC-autorisatie ingeschakeld met behulp van de opdracht [az keyvault create][az-keyvault-create]. U kunt ook een bestaande sleutelkluis gebruiken als deze is geconfigureerd voor zowel beveiliging tegen opschonen als Azure RBAC-autorisatie:

   export KEYVAULT_NAME="keyvault-workload-id$RANDOM_ID" # Ensure the key vault name is between 3-24 characters
   az keyvault create \
       --name "${KEYVAULT_NAME}" \
       --resource-group "${RESOURCE_GROUP}" \
       --location "${LOCATION}" \
       --enable-purge-protection \
       --enable-rbac-authorization
   

2. Haal de resource-id van de sleutelkluis op en sla deze op in een omgevingsvariabele met behulp van de opdracht [az keyvault show][az-keyvault-show].

   export KEYVAULT_RESOURCE_ID=$(az keyvault show --resource-group "${RESOURCE_GROUP}" \
       --name "${KEYVAULT_NAME}" \
       --query id \
       --output tsv)
   

RBAC-machtigingen toewijzen voor sleutelkluisbeheer

1. Haal de object-id van de aanroeper op en sla deze op in een omgevingsvariabele met behulp van de opdracht [az ad signed-in-user show][az-ad-signed-in-user-show].

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

2. Wijs uzelf de azure RBAC Key Vault Secrets Officer-rol toe, zodat u een geheim kunt maken in de nieuwe sleutelkluis met behulp van de opdracht [az role assignment create][az-role-assignment-create].

   az role assignment create --assignee "${CALLER_OBJECT_ID}" \
       --role "Key Vault Secrets Officer" \
       --scope "${KEYVAULT_RESOURCE_ID}"
   

Geheime toegang maken en configureren

1. Maak een geheim in de sleutelkluis met behulp van de opdracht [az keyvault secret set][az-keyvault-secret-set].

   export KEYVAULT_SECRET_NAME="my-secret$RANDOM_ID"
   az keyvault secret set \
       --vault-name "${KEYVAULT_NAME}" \
       --name "${KEYVAULT_SECRET_NAME}" \
       --value "Hello\!"
   

2. Haal de principal-id van de door de gebruiker toegewezen beheerde identiteit op en sla deze op in een omgevingsvariabele met behulp van de opdracht [az identity show][az-identity-show].

   export IDENTITY_PRINCIPAL_ID=$(az identity show \
       --name "${USER_ASSIGNED_IDENTITY_NAME}" \
       --resource-group "${RESOURCE_GROUP}" \
       --query principalId \
       --output tsv)
   

3. Wijs de rol Key Vault Secrets User toe aan de door de gebruiker toegewezen beheerde identiteit met behulp van de opdracht [az role assignment create][az-role-assignment-create]. Deze stap geeft de beheerde identiteit toestemming om geheimen uit de sleutelkluis te lezen.

   az role assignment create \
       --assignee-object-id "${IDENTITY_PRINCIPAL_ID}" \
       --role "Key Vault Secrets User" \
       --scope "${KEYVAULT_RESOURCE_ID}" \
       --assignee-principal-type ServicePrincipal
   

4. Maak een omgevingsvariabele voor de sleutelkluis-URL met behulp van de opdracht [az keyvault show][az-keyvault-show]:

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

Een verificatiepod implementeren en toegang testen

1. Implementeer een pod om te controleren of de workloadidentiteit toegang heeft tot het geheim in de sleutelkluis. In het volgende voorbeeld wordt de ghcr.io/azure/azure-workload-identity/msal-go afbeelding gebruikt, die een voorbeeldtoepassing bevat die een geheim ophaalt uit Azure Key Vault met behulp van De Workload-id van Microsoft Entra:

   kubectl apply -f - <<EOF
   apiVersion: v1
   kind: Pod
   metadata:
       name: sample-workload-identity-key-vault
       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
   

2. Wacht tot de pod de Ready status heeft met behulp van de kubectl wait opdracht.

   kubectl wait --namespace ${SERVICE_ACCOUNT_NAMESPACE} --for=condition=Ready pod/sample-workload-identity-key-vault --timeout=120s
   

3. Controleer of de SECRET_NAME omgevingsvariabele is ingesteld in de pod met behulp van de kubectl describe opdracht.

   kubectl describe pod sample-workload-identity-key-vault | grep "SECRET_NAME:"
   

   Als dit lukt, moet de uitvoer er ongeveer uitzien als in het volgende voorbeeld:

   SECRET_NAME: ${KEYVAULT_SECRET_NAME}
   

4. Controleer of pods een token kunnen ophalen en toegang hebben tot de resource met behulp van de kubectl logs opdracht.

   kubectl logs sample-workload-identity-key-vault
   

   Als dit lukt, moet de uitvoer er ongeveer uitzien als in het volgende voorbeeld:

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

   Belangrijk

   Het kan tot 10 minuten duren voordat Azure RBAC-roltoewijzingen zijn doorgegeven. Als de pod geen toegang heeft tot het geheim, moet u mogelijk wachten totdat de roltoewijzing is doorgegeven. Zie Problemen met Azure RBAC oplossen voor meer informatie.

Op een AKS-cluster de werkbelasting-id van Microsoft Entra uitschakelen

• Schakel de Microsoft Entra-workload-id uit op het AKS-cluster waarvoor het is ingeschakeld en geconfigureerd. Werk het AKS-cluster bij met behulp van de az aks update opdracht met de --disable-workload-identity parameter.

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

Verwante inhoud

In dit artikel hebt u een Kubernetes-cluster geïmplementeerd en geconfigureerd voor het gebruik van de Microsoft Entra Workload ID ter voorbereiding van toepassingsworkloads om te authenticeren met die referentie-id. U bent nu klaar om uw toepassing te implementeren en deze te configureren voor het gebruik van de workloadidentiteit met de nieuwste versie van de Azure Identity-clientbibliotheek . Als u uw toepassing niet kunt herschrijven om de nieuwste versie van de clientbibliotheek te gebruiken, kunt u uw toepassingspod instellen voor verificatie met beheerde identiteit met workloadidentiteit als een kortetermijnmigratieoplossing.

De serviceconnectorintegratie vereenvoudigt de verbindingsconfiguratie voor AKS-workloads en Azure-backingservices. Het verwerkt verificatie- en netwerkconfiguraties veilig en volgt aanbevolen procedures voor het maken van verbinding met Azure-services. Zie Verbinding maken met Azure OpenAI in Foundry-modellen in AKS met behulp van Microsoft Entra Workload Identity en de inleiding tot de Service Connector voor meer informatie.