Migreren van beheerde pod-identiteit naar workloadidentiteit

Artikel
10/15/2024

Dit artikel is gericht op het migreren van een door pod beheerde identiteit naar Microsoft Entra Workload-ID voor uw AKS-cluster (Azure Kubernetes Service). Het biedt ook richtlijnen, afhankelijk van de versie van de Azure Identity-clientbibliotheek die wordt gebruikt door uw toepassing op basis van containers.

Als u niet bekend bent met Microsoft Entra Workload-ID, raadpleegt u het volgende artikel overzicht.

Voordat u begint

Azure CLI versie 2.47.0 of hoger. Voer az --version deze uit om de versie te vinden en voer deze uit az upgrade om de versie te upgraden. Als u Azure CLI 2.0 wilt installeren of upgraden, raadpleegt u Azure CLI 2.0 installeren.

Migratiescenario's

In deze sectie wordt uitgelegd welke migratieopties beschikbaar zijn, afhankelijk van welke versie van de Azure Identity SDK is geïnstalleerd.

Voor beide scenario's moet de federatieve vertrouwensrelatie zijn ingesteld voordat u uw toepassing bijwerkt om de workloadidentiteit te gebruiken. Hier volgen de minimale stappen die vereist zijn:

Maak een referenties voor een beheerde identiteit .
Koppel de beheerde identiteit aan het kubernetes-serviceaccount dat al is gebruikt voor de door pod beheerde identiteit of maak een nieuw Kubernetes-serviceaccount en koppel deze vervolgens aan de beheerde identiteit.
Een federatieve vertrouwensrelatie tot stand brengen tussen de beheerde identiteit en de Microsoft Entra-id.

Migreren vanaf de nieuwste versie

Als uw toepassing al gebruikmaakt van de nieuwste versie van de Azure Identity SDK, voert u de volgende stappen uit om de verificatieconfiguratie te voltooien:

Implementeer de workloadidentiteit parallel met een door pod beheerde identiteit. U kunt de implementatie van uw toepassing opnieuw starten om de workloadidentiteit te gebruiken, waarbij de OIDC-aantekeningen automatisch in de toepassing worden ingevoerd.
Nadat u hebt gecontroleerd of de toepassing kan worden geverifieerd, kunt u de door pod beheerde identiteitsaantekeningen uit uw toepassing verwijderen en vervolgens de door pod beheerde identiteitsinvoegtoepassing verwijderen.

Migreren van oudere versie

Als uw toepassing niet de nieuwste versie van de Azure Identity SDK gebruikt, hebt u twee opties:

U kunt een migratie-sidecar gebruiken die we bieden in uw Linux-toepassingen, die de IMDS-transacties die uw toepassing uitvoert, proxy's uitvoert naar OpenID Connect (OIDC). De sidecar van de migratie is niet bedoeld als een langetermijnoplossing, maar een manier om snel aan de slag te gaan met workloadidentiteit. Voer de volgende stappen uit:
- Implementeer de workload met een migratie-sidecar om de IMDS-transacties van de toepassing te proxyen.
- Controleer of de verificatietransacties zijn voltooid.
- Plan het werk voor de toepassingen om de SDK bij te werken naar een ondersteunde versie.
- Zodra de SDK's zijn bijgewerkt naar de ondersteunde versie, kunt u de proxy-sidecar verwijderen en de toepassing opnieuw implementeren.
Notitie

De migratie-sidecar wordt niet ondersteund voor productiegebruik. Deze functie is bedoeld om u tijd te geven om de SDK's van uw toepassing te migreren naar een ondersteunde versie en niet bedoeld of bedoeld om een langetermijnoplossing te zijn. De migratie-sidecar is alleen beschikbaar voor Linux-containers, omdat alleen door pods beheerde identiteiten worden geleverd met Linux-knooppuntgroepen.
Herschrijf uw toepassing ter ondersteuning van de nieuwste versie van de Azure Identity-clientbibliotheek . Voer daarna de volgende stappen uit:
- Start de implementatie van uw toepassing opnieuw om te verifiëren met behulp van de workloadidentiteit.
- Zodra u hebt gecontroleerd of de verificatietransacties zijn voltooid, kunt u de door pod beheerde identiteitsaantekeningen uit uw toepassing verwijderen en vervolgens de door pod beheerde identiteitsinvoegtoepassing verwijderen.

Een beheerde identiteit maken

Als u geen beheerde identiteit hebt gemaakt en toegewezen aan uw pod, voert u de volgende stappen uit om de benodigde machtigingen te maken en de benodigde machtigingen te verlenen voor opslag, Key Vault of alle resources waarmee uw toepassing moet worden geverifieerd in Azure.

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 account set --subscription "subscriptionID"

az identity create --name "userAssignedIdentityName" --resource-group "resourceGroupName" --location "location" --subscription "subscriptionID"

export USER_ASSIGNED_CLIENT_ID="$(az identity show --resource-group "resourceGroupName" --name "userAssignedIdentityName" --query 'clientId' -otsv)"

Verdeel de beheerde identiteit de machtigingen die nodig zijn voor toegang tot de resources in Azure die nodig zijn. Zie Een beheerde identiteit toegang tot een resource toewijzen voor meer informatie over hoe u dit doet.
Voer de volgende opdracht uit om de URL van de OIDC Issuer op te halen en op te slaan in een omgevingsvariabele. Vervang de standaardwaarden voor de clusternaam en de naam van de resourcegroep.
```
export AKS_OIDC_ISSUER="$(az aks show --name myAKSCluster --resource-group myResourceGroup --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/00000000-0000-0000-0000-000000000000/
```
De verlener is standaard ingesteld op het gebruik van de basis-URL https://{region}.oic.prod-aks.azure.com/{uuid}, waarbij de waarde overeenkomt {region} met de locatie waarin het AKS-cluster wordt geïmplementeerd. De waarde {uuid} vertegenwoordigt de OIDC-sleutel.

Kubernetes-serviceaccount maken

Als u geen toegewezen Kubernetes-serviceaccount hebt gemaakt voor deze toepassing, voert u de volgende stappen uit om deze te maken en er vervolgens aantekeningen op te maken 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 --name myAKSCluster --resource-group "${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 identiteitsreferentievertrouwensrelatie tot stand brengen

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. Vervang de waarden resourceGroupName, userAssignedIdentityName, , federatedIdentityNameen serviceAccountNamespaceserviceAccountName.

az identity federated-credential create --name federatedIdentityName --identity-name userAssignedIdentityName --resource-group resourceGroupName --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.

De workload implementeren met sidecar voor migratie

Notitie

De migratie-sidecar wordt niet ondersteund voor productiegebruik. Deze functie is bedoeld om u tijd te geven om de SDK's van uw toepassing te migreren naar een ondersteunde versie en niet bedoeld of bedoeld om een langetermijnoplossing te zijn. De migratie-sidecar is alleen voor Linux-containers omdat door pods beheerde identiteiten alleen beschikbaar waren in Linux-knooppuntgroepen.

Als uw toepassing gebruikmaakt van een beheerde identiteit en nog steeds afhankelijk is van IMDS om een toegangstoken op te halen, kunt u de sidecar van de migratie van de workloadidentiteit gebruiken om te beginnen met migreren naar workloadidentiteit. Deze sidecar is een migratieoplossing en in de toepassingen op de lange termijn moet u hun code wijzigen om de nieuwste Azure Identity SDK's te gebruiken die ondersteuning bieden voor clientverklaringen.

Als u de workload wilt bijwerken of implementeren, voegt u deze podaantekeningen alleen toe als u de sidecar van de migratie wilt gebruiken. U injecteert de volgende aantekeningswaarden om de sidecar in uw podspecificatie te gebruiken:

azure.workload.identity/inject-proxy-sidecar - waarde is true of false
azure.workload.identity/proxy-sidecar-port - waarde is de gewenste poort voor de proxy sidecar. De standaardwaarde is 8000.

Wanneer een pod met de bovenstaande aantekeningen wordt gemaakt, wordt met de Azure Workload Identity die de webhook muteert, automatisch de init-container en proxy-sidecar in de podspecificatie geplaatst.

De webhook die al wordt uitgevoerd, voegt de volgende YAML-fragmenten toe aan de pod-implementatie. Hier volgt een voorbeeld van de gemuteerde podspecificatie:

apiVersion: v1
kind: Pod
metadata:
  name: httpbin-pod
  labels:
    app: httpbin
    azure.workload.identity/use: "true"
  annotations:
    azure.workload.identity/inject-proxy-sidecar: "true"
spec:
  serviceAccountName: workload-identity-sa
  initContainers:
  - name: init-networking
    image: mcr.microsoft.com/oss/azure/workload-identity/proxy-init:v1.1.0
    securityContext:
      capabilities:
        add:
        - NET_ADMIN
        drop:
        - ALL
      privileged: true
      runAsUser: 0
    env:
    - name: PROXY_PORT
      value: "8000"
  containers:
  - name: nginx
    image: nginx:alpine
    ports:
    - containerPort: 80
  - name: proxy
    image: mcr.microsoft.com/oss/azure/workload-identity/proxy:v1.1.0
    ports:
    - containerPort: 8000

Deze configuratie is van toepassing op elke configuratie waarin een pod wordt gemaakt. Nadat u uw toepassing hebt bijgewerkt of geïmplementeerd, kunt u controleren of de pod actief is met behulp van de opdracht kubectl describe pod . Vervang de waarde podName door de naam van de installatiekopie van uw geïmplementeerde pod.

kubectl describe pods podName

Gebruik de opdracht kubectl-logboeken om te controleren of de pod IMDS-transacties doorgeeft. Vervang de waarde podName door de installatiekopienaam van uw geïmplementeerde pod:

kubectl logs podName

De volgende logboekuitvoer lijkt op geslaagde communicatie via de proxy-sidecar. Controleer of in de logboeken een token is verkregen en of de GET-bewerking is geslaagd.

I0926 00:29:29.968723       1 proxy.go:97] proxy "msg"="starting the proxy server" "port"=8080 "userAgent"="azure-workload-identity/proxy/v0.13.0-12-gc8527f3 (linux/amd64) c8527f3/2022-09-26-00:19"
I0926 00:29:29.972496       1 proxy.go:173] proxy "msg"="received readyz request" "method"="GET" "uri"="/readyz"
I0926 00:29:30.936769       1 proxy.go:107] proxy "msg"="received token request" "method"="GET" "uri"="/metadata/identity/oauth2/token?resource=https://management.core.windows.net/api-version=2018-02-01&client_id=<client_id>"
I0926 00:29:31.101998       1 proxy.go:129] proxy "msg"="successfully acquired token" "method"="GET" "uri"="/metadata/identity/oauth2/token?resource=https://management.core.windows.net/api-version=2018-02-01&client_id=<client_id>"

Door pod beheerde identiteit verwijderen

Nadat u uw tests hebt voltooid en de toepassing een token kan ophalen met behulp van de proxy sidecar, kunt u de door Microsoft Entra-pod beheerde identiteitstoewijzing voor de pod uit uw cluster verwijderen en vervolgens de identiteit verwijderen.

Voer de opdracht az aks pod-identity delete uit om de identiteit uit uw pod te verwijderen. Dit moet alleen worden gedaan nadat alle pods in de naamruimte met behulp van de door pod beheerde identiteittoewijzing zijn gemigreerd om de sidecar te gebruiken.
```
az aks pod-identity delete --name podIdentityName --namespace podIdentityNamespace --resource-group myResourceGroup --cluster-name myAKSCluster
```

Volgende stappen

In dit artikel hebt u gezien hoe u uw pod kunt instellen voor verificatie met behulp van een workloadidentiteit als migratieoptie. Zie het volgende artikel Overzicht voor meer informatie over Microsoft Entra Workload-ID.

Delen via