Workloadidentiteit implementeren en configureren op een AKS-cluster (Azure Kubernetes Service)

Azure Kubernetes Service (AKS) is een beheerde Kubernetes-service waarmee u Kubernetes-clusters snel kunt implementeren en beheren. In dit artikel leert u het volgende:

  • Een AKS-cluster implementeren met behulp van de Azure CLI met de OpenID Verbinding maken Issuer en een Microsoft Entra Workload-ID
  • Toegang verlenen tot uw Azure Key Vault
  • Een Microsoft Entra Workload-ID- en Kubernetes-serviceaccount maken
  • Configureer de beheerde identiteit voor tokenfederatie.

In dit artikel wordt ervan uitgegaan dat u basiskennis hebt van Kubernetes-concepten. Zie Kubernetes-kernconcepten voor Azure Kubernetes Service (AKS) voor meer informatie. Als u niet bekend bent met Microsoft Entra Workload-ID, raadpleegt u het volgende artikel overzicht.

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

  • De identiteit die u gebruikt om uw cluster te maken, heeft de juiste minimale machtigingen. Zie Toegangs- en identiteitsopties voor Azure Kubernetes Service (AKS) voor meer informatie over toegang en identiteit voor AKS.

  • Als u meerdere Azure-abonnementen hebt, selecteert u de juiste abonnements-id waarin de resources moeten worden gefactureerd met behulp van de opdracht az account .

Notitie

In plaats van alle stappen handmatig te configureren, is er een andere implementatie met de naam Service Verbinding maken or waarmee u bepaalde stappen automatisch kunt configureren en hetzelfde resultaat kunt bereiken. Zie ook: Zelfstudie: Verbinding maken naar Een Azure-opslagaccount in Azure Kubernetes Service (AKS) met Service Verbinding maken or met behulp van workloadidentiteit.

Omgevingsvariabelen exporteren

Om de stappen voor het configureren van de vereiste identiteiten te vereenvoudigen, definiëren de onderstaande stappen omgevingsvariabelen voor referentie op het cluster.

Voer de volgende opdrachten uit om deze variabelen te maken. Vervang de standaardwaarden voor RESOURCE_GROUP, LOCATION, SERVICE_ACCOUNT_NAME, , SUBSCRIPTION, en FEDERATED_IDENTITY_CREDENTIAL_NAMEUSER_ASSIGNED_IDENTITY_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"

Een AKS-cluster maken

Maak een AKS-cluster met behulp van de opdracht az aks create met de --enable-oidc-issuer parameter om de OIDC Issuer te gebruiken. In het volgende voorbeeld wordt een cluster met de naam myAKSCluster gemaakt met één knooppunt in de myResourceGroup:

az aks create -g "${RESOURCE_GROUP}" -n myAKSCluster --enable-oidc-issuer --enable-workload-identity --generate-ssh-keys

Na enkele minuten is de opdracht voltooid en retourneert deze informatie over het cluster in JSON-indeling.

Notitie

Wanneer u een AKS-cluster maakt, wordt automatisch een tweede resourcegroep gemaakt om de AKS-resources op te slaan. Zie Waarom zijn er twee resourcegroepen gemaakt met AKS? voor meer informatie.

Een bestaand AKS-cluster bijwerken

U kunt een AKS-cluster bijwerken met behulp van de opdracht az aks update met de --enable-oidc-issuer parameter --enable-workload-identity voor het gebruik van de OIDC Issuer en het inschakelen van de workloadidentiteit. In het volgende voorbeeld wordt een cluster met de naam myAKSCluster bijgewerkt:

az aks update -g "${RESOURCE_GROUP}" -n myAKSCluster --enable-oidc-issuer --enable-workload-identity

De URL van de OIDC-verlener ophalen

Voer de volgende opdracht uit om de URL van de OIDC Issuer op te halen en op te slaan in een omgevingsvariabele. Vervang de standaardwaarde voor de argumenten -n. Dit is de naam van het cluster:

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

De variabele moet de URL van de verlener bevatten die vergelijkbaar is 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 overeenkomt {region} met de locatie waarin het AKS-cluster wordt geïmplementeerd. De waarde {uuid} vertegenwoordigt de OIDC-sleutel.

Een beheerde identiteit maken

Gebruik de azure CLI az account set command om een specifiek abonnement in te stellen op het huidige actieve abonnement. Gebruik vervolgens de opdracht az identity create om een beheerde identiteit te maken.

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

Vervolgens gaan we een variabele maken voor de beheerde identiteit-id.

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

Kubernetes-serviceaccount maken

Maak een Kubernetes-serviceaccount en annotaeer dit met de client-id van de beheerde identiteit die u in de vorige stap hebt gemaakt. Gebruik de opdracht az aks get-credentials en vervang de waarden voor de clusternaam en de naam van de resourcegroep.

az aks get-credentials -n myAKSCluster -g "${RESOURCE_GROUP}"

Kopieer en plak de volgende invoer met meerdere regels in de Azure CLI.

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

De volgende uitvoer lijkt op een geslaagde creatie van de identiteit:

serviceaccount/workload-identity-sa created

Federatieve identiteitsreferenties instellen

Gebruik de opdracht az identity federated-credential create om de federatieve identiteitsreferentie te maken tussen de beheerde identiteit, de verlener van het serviceaccount en het onderwerp.

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 een aantal seconden voordat de federatieve identiteitsreferentie wordt doorgegeven nadat deze in eerste instantie is toegevoegd. Als er direct na het toevoegen van de federatieve identiteitsreferentie een tokenaanvraag wordt gedaan, kan dit enkele minuten tot een fout leiden omdat de cache wordt gevuld in de map met oude gegevens. U kunt dit probleem voorkomen door een kleine vertraging toe te voegen nadat u de federatieve identiteitsreferentie hebt toegevoegd.

Uw toepassing implementeren

Wanneer u uw toepassingspods implementeert, moet het manifest verwijzen naar het serviceaccount dat is gemaakt in de stap Kubernetes-serviceaccount maken. In het volgende manifest ziet u hoe u naar het account verwijst, met name metadata\namespace en spec\serviceAccountName-eigenschappen :

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

Belangrijk

Zorg ervoor dat uw toepassingspods met behulp van workloadidentiteit het volgende label azure.workload.identity/use: "true" hebben toegevoegd aan de podspecificatie, anders mislukken de pods nadat ze opnieuw zijn opgestart.

Optioneel: machtigingen verlenen voor toegang tot Azure Key Vault

Deze stap is nodig als u toegang nodig hebt tot geheimen, sleutels en certificaten die vanuit een pod zijn gekoppeld in Azure Key Vault. Voer de volgende stappen uit om toegang te configureren met een beheerde identiteit. Bij deze stappen wordt ervan uitgegaan dat u al een Azure Key Vault hebt gemaakt en geconfigureerd in uw abonnement. Als u er nog geen hebt, raadpleegt u Een Azure Key Vault maken met behulp van de Azure CLI.

Voordat u doorgaat, hebt u de volgende informatie nodig:

  • Naam van de sleutelkluis
  • Resourcegroep met de Sleutelkluis

U kunt deze informatie ophalen met behulp van de Azure CLI-opdracht: az keyvault list.

  1. Stel een toegangsbeleid in voor de beheerde identiteit voor toegang tot geheimen in uw Key Vault door de volgende opdrachten uit te voeren:

    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. Maak een geheim in Key Vault:

    export KEYVAULT_SECRET_NAME="my-secret"
    
    az keyvault secret set --vault-name "${KEYVAULT_NAME}" \
       --name "${KEYVAULT_SECRET_NAME}" \
       --value "Hello\!"
    
  3. Url van Key Vault exporteren:

    export KEYVAULT_URL="$(az keyvault show -g ${KEYVAULT_RESOURCE_GROUP} -n ${KEYVAULT_NAME} --query properties.vaultUri -o tsv)"
    
  4. Implementeer een pod die verwijst naar het serviceaccount en de Key Vault-URL hierboven:

    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
    

Als u wilt controleren of alle eigenschappen correct worden geïnjecteerd door de webhook, gebruikt u de opdracht kubectl describe :

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

Als dit lukt, moet de uitvoer er ongeveer als volgt uitzien:

      SECRET_NAME:                 ${KEYVAULT_SECRET_NAME}

Gebruik de opdracht kubectl-logboeken om te controleren of de pod een token kan ophalen en toegang heeft tot de resource:

kubectl logs quick-start

Als dit lukt, moet de uitvoer er ongeveer als volgt uitzien:

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

Workloadidentiteit uitschakelen

Als u de Microsoft Entra Workload-ID wilt uitschakelen op het AKS-cluster waarvoor het is ingeschakeld en geconfigureerd, kunt u de volgende opdracht uitvoeren:

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

Volgende stappen

In dit artikel hebt u een Kubernetes-cluster geïmplementeerd en geconfigureerd voor het gebruik van een workloadidentiteit ter voorbereiding op toepassingsworkloads voor verificatie met die referentie. 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.