Migration von einer Pod-verwalteten Identität zur Workloadidentität

Artikel
07/31/2023

Dieser Artikel konzentriert sich auf die Migration von einer podseitig verwalteten Identität zur Microsoft Entra-Workload-ID für Ihren AKS-Cluster (Azure Kubernetes Service). Er bietet auch Anleitungen, abhängig von der Version der Azure Identity-Clientbibliothek, die von Ihrer containerbasierten Anwendung verwendet wird.

Wenn Sie noch nicht mit der Microsoft Entra-Workload-ID vertraut sind, lesen Sie den folgenden Übersichtsartikel.

Voraussetzungen

Azure CLI-Version 2.47.0 oder höher. Führen Sie az --version aus, um die Version zu finden, und führen Sie az upgrade aus, um ein Upgrade für die Version durchzuführen. Informationen zum Durchführen einer Installation oder eines Upgrades finden Sie bei Bedarf unter Installieren der Azure CLI.

Migrationsszenarios

In diesem Abschnitt werden die verfügbaren Migrationsoptionen erläutert, je nachdem, welche Version des Azure Identity SDK installiert ist.

Für beide Szenarien muss die Verbundvertrauensstellung eingerichtet sein, bevor Sie Ihre Anwendung so aktualisieren, dass sie die Workloadidentität verwendet. Im Folgenden sind die erforderlichen Mindestschritte aufgeführt:

Erstellen Sie Anmeldeinformationen für verwaltete Identitäten.
Ordnen Sie die verwaltete Identität dem Kubernetes-Dienstkonto zu, das bereits für die Pod-verwaltete Identität verwendet wird, oder erstellen Sie ein neues Kubernetes-Dienstkonto, und ordnen Sie es dann der verwalteten Identität zu.
Richten Sie eine Verbundvertrauensstellung zwischen der verwalteten Identität und Microsoft Entra ID ein.

Migrieren von der neuesten Version

Wenn Ihre Anwendung bereits die neueste Version des Azure Identity SDK verwendet, führen Sie die folgenden Schritte aus, um die Authentifizierungskonfiguration abzuschließen:

Stellen Sie die Workloadidentität parallel zur podseitig verwalteten Identität bereit. Sie können die Anwendungsbereitstellung neu starten, um mit der Verwendung der Workloadidentität zu beginnen, wobei die OIDC-Anmerkungen automatisch in die Anwendung eingefügt werden.
Nachdem Sie überprüft haben, ob die Anwendung erfolgreich authentifizieren kann, können Sie die Pod-verwalteten Identitätsanmerkungen aus Ihrer Anwendung entfernen und dann das Pod-verwaltete Identitäts-Add-On entfernen.

Migrieren von einer älteren Version

Wenn Ihre Anwendung nicht die neueste Version des Azure Identity SDK verwendet, haben Sie zwei Möglichkeiten:

Sie können einen von uns in Ihren Linux-Anwendungen bereitgestellten Migrations-Sidecar verwenden, der die von Ihrer Anwendung übernommenen IMDS-Transaktionen als Proxy zu OpenID Connect (OIDC) weiterleitet. Der Migrations-Sidecar ist nicht als langfristige Lösung gedacht, sondern als eine Möglichkeit, Workloadidentitäten schnell einzurichten und auszuführen. Führen Sie die folgenden Schritte aus:
- Stellen Sie die Workload mit dem Migrations-Sidecar bereit, um die IMDS-Transaktionen der Anwendung als Proxy zu verwenden.
- Überprüfen Sie, ob die Authentifizierungstransaktionen erfolgreich abgeschlossen wurden.
- Planen Sie die Aktualisierung der Anwendungs-SDKs auf eine unterstützte Version.
- Nachdem die SDKs auf die unterstützte Version aktualisiert wurden, können Sie das Proxy-Sidecar entfernen und die Anwendung erneut bereitstellen.
Hinweis

Das Migrations-Sidecar wird für die Verwendung in der Produktion nicht unterstützt. Dieses Feature soll Ihnen Zeit für die Migration Ihrer Anwendungs-SDK zu einer unterstützten Version geben und ist nicht als langfristige Lösung gedacht oder beabsichtigt. Der Migrations-Sidecar ist nur für Linux-Container verfügbar, da podverwaltete Identitäten nur mit Linux-Knotenpools bereitgestellt werden.
Schreiben Sie Ihre Anwendung neu, um die neueste Version der Azure Identity-Clientbibliothek zu unterstützen. Führen Sie anschließend die folgenden Schritte aus:
- Starten Sie die Anwendungsbereitstellung neu, um mit der Authentifizierung mithilfe der Workloadidentität zu beginnen.
- Nachdem Sie überprüft haben, dass die Authentifizierungstransaktionen erfolgreich abgeschlossen wurden, können Sie die Pod-verwalteten Identitätsanmerkungen aus Ihrer Anwendung entfernen und dann das Pod-verwaltete Identitäts-Add-On entfernen.

Erstellen einer verwalteten Identität

Wenn Sie keine verwaltete Identität erstellt und Ihrem Pod zugewiesen haben, führen Sie die folgenden Schritte durch, um die erforderlichen Berechtigungen für Speicher, Key Vault oder andere Ressourcen, mit denen sich Ihre Anwendung in Azure authentifizieren muss, zu erstellen und zu erteilen.

Verwenden Sie den Azure CLI-Befehl az account set zum Festlegen eines bestimmten Abonnements als aktuelles aktives Abonnement. Verwenden Sie dann den Befehl az identity create, um eine verwaltete Identität zu erstellen.

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)"

Gewähren Sie der verwalteten Identität die Berechtigungen, die für den Zugriff auf die Ressourcen in Azure erforderlich sind. Informationen hierzu finden Sie unter Zuweisen des Zugriffs einer verwalteten Identität auf eine Ressource.
Um die URL des OIDC-Ausstellers abzurufen und in einer Umgebungsvariable zu speichern, führen Sie den folgenden Befehl aus. Ersetzen Sie die Standardwerte für den Clusternamen und den Ressourcengruppennamen.
```
export AKS_OIDC_ISSUER="$(az aks show --name myAKSCluster --resource-group myResourceGroup --query "oidcIssuerProfile.issuerUrl" -o tsv)"
```
Die Variable sollte die Aussteller-URL ähnlich dem folgenden Beispiel enthalten:
```
https://eastus.oic.prod-aks.azure.com/00000000-0000-0000-0000-000000000000/00000000-0000-0000-0000-000000000000/
```
Standardmäßig ist für den Aussteller die Verwendung der Basis-URL https://{region}.oic.prod-aks.azure.com/{uuid} festgelegt, wobei der Wert für {region} dem Standort entspricht, in dem der AKS-Cluster bereitgestellt ist. Der Wert {uuid} stellt den OIDC-Schlüssel dar.

Erstellen eines Kubernetes-Dienstkontos

Wenn Sie kein dediziertes Kubernetes-Dienstkonto für diese Anwendung erstellt haben, führen Sie die folgenden Schritte aus, um es zu erstellen und dann mit der Client-ID der im vorherigen Schritt erstellten verwalteten Identität zu versehen. Verwenden Sie den Befehl az aks get-credentials, und ersetzen Sie die Werte für den Clusternamen und den Ressourcengruppennamen.

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

Kopieren Sie die folgende mehrzeilige Eingabe, und fügen Sie sie in die Azure CLI ein.

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

Die folgende Ausgabe ähnelt der erfolgreichen Erstellung der Identität:

Serviceaccount/workload-identity-sa created

Einrichten der Vertrauensstellung für Verbundidentitätsnachweise

Erstellen Sie mit dem Befehl az identity federated-credential create die Verbundidentitäts-Anmeldeinformationen in Verbindung mit der verwalteten Identität, dem Dienstkontoaussteller und dem Antragsteller. Ersetzen Sie die Werte resourceGroupName, userAssignedIdentityName, federatedIdentityName, serviceAccountNamespace und serviceAccountName.

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

Hinweis

Es dauert einige Sekunden, bis die Verbundidentitäts-Anmeldeinformationen nach dem erstmaligen Hinzufügen weitergegeben werden. Wenn eine Tokenanforderung unmittelbar nach dem Hinzufügen der Verbundidentitäts-Anmeldeinformationen erfolgt, kann dies einige Minuten lang zu Fehlern führen, da der Cache im Verzeichnis noch mit alten Daten gefüllt wird. Um dieses Problem zu vermeiden, können Sie eine kleine Verzögerung nach dem Hinzufügen der Verbundidentitäts-Anmeldeinformationen hinzufügen.

Bereitstellen der Workload mit dem Migrations-Sidecar

Hinweis

Das Migrations-Sidecar wird für die Verwendung in der Produktion nicht unterstützt. Dieses Feature soll Ihnen Zeit für die Migration Ihrer Anwendungs-SDK zu einer unterstützten Version geben und ist nicht als langfristige Lösung gedacht oder beabsichtigt. Der Migrations-Sidecar ist nur für Linux-Container verfügbar, da podverwaltete Identitäten nur auf Linux-Knotenpools verfügbar waren.

Wenn Ihre Anwendung eine verwaltete Identität verwendet und weiterhin auf IMDS angewiesen ist, um ein Zugriffstoken abzurufen, können Sie die Workload Identity-Migrations-Sidecar verwenden, um mit der Migration zur Workloadidentität zu beginnen. Bei diesem Sidecar handelt es sich um eine Migrationslösung. Bei langfristigen Anwendungen sollten Sie den Code so ändern, dass er die neuesten Azure Identity SDKs verwendet, die Clientassertion unterstützen.

Um die Workload zu aktualisieren oder bereitzustellen, fügen Sie diese Podanmerkungen nur hinzu, wenn Sie den Migrations-Sidecar verwenden möchten. Um den Sidecar in Ihrer Podspezifikation zu verwenden, fügen Sie die folgenden annotation-Werte ein:

azure.workload.identity/inject-proxy-sidecar – Wert ist true oder false.
azure.workload.identity/proxy-sidecar-port – Wert ist der gewünschte Port für den Proxy-Sidecar. Der Standardwert ist 8000.

Wenn ein Pod mit den obigen Anmerkungen erstellt wird, fügt der Webhook zum Ändern der Azure-Workloadidentität automatisch den Init-Container und den Proxy-Sidecar in die Podspezifikation ein.

Der bereits ausgeführte Webhook fügt der Podbereitstellung die folgenden YAML-Codeausschnitte hinzu. Im Folgenden sehen Sie ein Beispiel für die geänderte Podspezifikation:

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

Diese Konfiguration gilt für jede Konfiguration, in der ein Pod erstellt wird. Nachdem Sie Ihre Anwendung aktualisiert oder bereitgestellt haben, können Sie mit dem Befehl kubectl describe pod überprüfen, ob sich der Pod in einem ausgeführten Zustand befindet. Ersetzen Sie den Wert podName durch den Imagenamen Ihres bereitgestellten Pods.

kubectl describe pods podName

Um sicherzustellen, dass der Pod IMDS-Transaktionen übergibt, verwenden Sie den Befehl kubectl logs. Ersetzen Sie den Wert podName durch den Imagenamen Ihres bereitgestellten Pods:

kubectl logs podName

Die folgende Protokollausgabe ähnelt der erfolgreichen Kommunikation über den Proxy-Sidecar. Vergewissern Sie sich in den Protokollen, dass der Abruf eines Tokens und der GET-Vorgang erfolgreich waren.

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>"

Entfernen einer podseitig verwalteten Identität

Nachdem Sie Ihre Tests abgeschlossen haben und die Anwendung erfolgreich ein Token mithilfe des Proxy-Sidecars abrufen kann, können Sie die podseitig verwaltete Microsoft Entra-Identitätszuordnung für den Pod aus Ihrem Cluster entfernen und dann die Identität entfernen.

Führen Sie den Befehl az aks pod-identity delete aus, um die Identität aus Ihrem Pod zu entfernen. Dies sollte nur erfolgen, nachdem alle Pods im Namespace mithilfe der podseitig verwalteten Identitätszuordnung migriert wurden, um den Sidecar zu verwenden.
```
az aks pod-identity delete --name podIdentityName --namespace podIdentityNamespace --resource-group myResourceGroup --cluster-name myAKSCluster
```

Nächste Schritte

In diesem Artikel wurde gezeigt, wie Sie Ihren Pod so einrichten, dass die Authentifizierung mithilfe einer Workloadidentität als Migrationsoption erfolgt. Weitere Informationen zur Microsoft Entra-Workload-ID finden Sie im folgenden Übersichtsartikel.

Share via