Einrichten von Identitätsbindungen für Azure Kubernetes Service (AKS) (Vorschau)

Richten Sie Identitätsbindungen auf Ihren Azure Kubernetes Service (AKS)-Clustern ein, um eine benutzerzugewiesene verwaltete Identität (UAMI) über mehrere Cluster hinweg zuzuordnen und gleichzeitig eine einzige Verbundidentitäts-Anmeldeinformation (FIC) zu verwenden. Mit diesem Setup können Sie die Microsoft Entra-Authentifizierung für Workloads skalieren, ohne FIC-Grenzwerte zu erreichen.

Voraussetzungen

Überprüfen Sie die Konzepten von Identitätsbindungen, um zu verstehen, wie sie funktionieren.
Azure CLI, Version 2.73.0 oder höher. Verwenden Sie den az version Befehl, um Ihre Version zu überprüfen. Informationen zum Installieren oder Aktualisieren der Azure CLI finden Sie unter Installieren der Azure CLI.
Die Azure CLI Erweiterungsversion aks-preview18.0.0b26 oder höher ist installiert.
Die IdentityBindingPreview Feature-Flag, die für Ihr Abonnement aktiviert ist.
Sie benötigen die folgenden Azure-Berechtigungen für den Identitäts- und Clusterbereich: Microsoft.ManagedIdentity/userAssignedIdentities/federatedIdentityCredentials/write und Microsoft.ContainerService/managedClusters/write.
Sie benötigen Kubernetes-Clusteradministratorberechtigungen (oder gleichwertige), um ClusterRole- und ClusterRoleBinding-Ressourcen zu erstellen.

Installieren oder Aktualisieren der `aks-preview` Erweiterung

Installieren oder aktualisieren Sie die Azure CLI-Erweiterung aks-preview auf die neueste Version, indem Sie den folgenden az extension add oder az extension update Befehl verwenden:
```
# 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
```

Aktivieren der `IdentityBindingPreview` Featurekennzeichnung

Registrieren Sie die IdentityBindingPreview Featurekennzeichnung für Ihr Azure-Abonnement mithilfe des az feature register Befehls.
```
az feature register --namespace Microsoft.ContainerService --name IdentityBindingPreview
```
Die Featureregistrierung kann bis zu 15 Minuten dauern.
Warten Sie, bis die Registrierung unter Verwendung des az feature show Befehls abgeschlossen ist.
```
az feature show --namespace Microsoft.ContainerService --name IdentityBindingPreview
```
Sobald das Feature als Registered angezeigt wird, aktualisieren Sie die Anbieterregistrierung mithilfe des az provider register Befehls.
```
az provider register --namespace Microsoft.ContainerService
```

Einschränkungen

Identitätsbindungen werden für Cluster, die mit der VNet-Integration des API-Servers konfiguriert sind, noch nicht unterstützt.

Erstellen von Testressourcen

Erstellen Sie mithilfe des Befehls az group create eine Azure-Ressourcengruppe.

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

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

Erstellen Sie einen AKS-Cluster mit Workload-Identität und aktiviertem OIDC-Issuer unter Verwendung des az aks create-Befehls mit den --enable-workload-identity- und --enable-oidc-issuer-Flags.
```
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
```
Erstellen Sie mithilfe des az identity create Befehls eine vom Benutzer zugewiesene verwaltete Identität (Managed Identity, UAMI).
```
export MI_NAME="ib-test-mi"
az identity create --resource-group $RESOURCE_GROUP --name $MI_NAME
```

Überprüfen Sie die Version des Workload-Identitätswebhooks

Für die Identitätsbindung ist die Vorschauversion des Workload-Identitätswebhooks erforderlich. Überprüfen Sie die installierte Webhook-Version mit dem folgenden kubectl get pods Befehl:
```
kubectl -n kube-system get pods -l azure-workload-identity.io/system=true -o yaml | grep v1.6.0
```
Die Ausgabe sollte v1.6.0-alpha.1 im Imagetag anzeigen, was bestätigt, dass die richtige Version installiert ist.

Abrufen der UAMI-IDs

Rufen Sie die Ressourcen-, Prinzipal-, Client- und Mandanten-IDs der UAMI ab, und legen Sie sie mithilfe der folgenden az identity show Befehle als Umgebungsvariablen fest:

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)

Erstellen einer Identitätsbindung

Ordnen Sie das UAMI dem AKS-Cluster mit einer Identitätsbindung mithilfe des az aks identity-binding create Befehls zu.
```
az aks identity-binding create --resource-group $RESOURCE_GROUP --cluster-name $CLUSTER_NAME --name "${MI_NAME}-ib" --managed-identity-resource-id $MI_RESOURCE_ID
```
Hinweis

Wenn Sie eine Identitätsbindung erstellen, erstellt AKS automatisch eine Verbundidentitäts-Anmeldeinformation (FIC) mit dem Namen aks-identity-binding unter der UAMI. Diese Anmeldeinformationen werden von AKS verwaltet. Ändern oder löschen Sie sie nicht, während Identitätsbindungen verwendet werden. Das für Identitätsbindungen erstellte FIC wird für alle Identitätsbindungen freigegeben, die auf dasselbe UAMI verweisen.

Rufen Sie die OIDC-Aussteller-URL für das UAMI ab

Rufen Sie die OIDC-Aussteller-URL ab, die der UAMI zugeordnet ist, indem Sie die Identitätsbindung mithilfe des az aks identity-binding show Befehls prüfen.

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

Komprimierte Beispielausgabe:

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

Herstellen einer Verbindung mit dem AKS-Cluster

Rufen Sie die AKS-Clusteranmeldeinformationen mithilfe des az aks get-credentials Befehls ab, und speichern Sie sie in einer separaten Kubeconfig-Datei:
```
az aks get-credentials --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME -a -f "${CLUSTER_NAME}.kubeconfig"
```
Legen Sie die KUBECONFIG Umgebungsvariable so fest, dass sie auf die neue Kubeconfig-Datei verweist:
```
export KUBECONFIG="$(pwd)/${CLUSTER_NAME}.kubeconfig"
```

Autorisieren von Namespaces und Dienstkonten

Konfigurieren Sie die rollenbasierte Zugriffssteuerung (RBAC), um bestimmten Subjekten die Berechtigung zur Verwendung der verwalteten Identität per Identitätsbindung zu erteilen, indem Sie das folgende Manifest mit dem folgenden kubectl apply Befehl anwenden.

Hinweis

Im folgenden Beispiel wird explizit auf das demo Dienstkonto im demo Namespace verwiesen. Während der explizite Verweis auf ein bestimmtes Dienstkonto eine Option ist, ist es auch möglich, auf eine Sammlung von Dienstkonten zu verweisen.subjects Weitere Informationen finden Sie unter Verweisen auf Themen in der Kubernetes-Dokumentation.

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

Erstellen Sie einen Schlüsseltresor mit aktiviertem Löschschutz und aktivierter Azure RBAC-Autorisierung.

Erstellen Sie einen Schlüsseltresor mit Löschschutz und Azure RBAC-Autorisierung. Verwenden Sie dazu den az keyvault create-Befehl mit den Flags --enable-purge-protection und --enable-rbac-authorization. Sie können auch einen vorhandenen Schlüsseltresor verwenden, wenn er sowohl für den Löschschutz als auch für die Azure RBAC-Autorisierung konfiguriert ist.
```
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
```

Abrufen der Ressourcen-ID und -URL

Rufen Sie die Ressourcen-ID des Schlüsseltresors mithilfe des Befehls az keyvault show ab, und legen Sie sie als Umgebungsvariable fest.

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

Rufen Sie die Schlüsseltresor-URL mithilfe des az keyvault show Befehls ab, und legen Sie sie als Umgebungsvariable fest:

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

Konfigurieren des Zugriffs auf den Schlüsseltresor und Erstellen eines Geheimnisses

Die folgenden Schritte zeigen, wie Sie auf geheime Schlüssel, Schlüssel oder Zertifikate in Azure Key Vault über den Pod zugreifen. In den Beispielen in diesem Abschnitt wird der Zugriff auf Geheimnisse im Schlüsseltresor für die Workloadidentität konfiguriert. Sie können jedoch ähnliche Schritte ausführen, um den Zugriff auf Schlüssel oder Zertifikate zu konfigurieren.

Das folgende Beispiel zeigt, wie Sie das Azure RBAC-Berechtigungsmodell verwenden, um dem Pod Zugriff auf den Schlüsseltresor zu gewähren. Weitere Informationen zum Azure RBAC-Berechtigungsmodell für Azure Key Vault finden Sie unter Erteilen der Berechtigung für Anwendungen für den Zugriff auf Azure Key Vault mithilfe von Azure RBAC.

Rufen Sie die Objekt-ID des angemeldeten Benutzers mithilfe des az ad signed-in-user show Befehls ab, und legen Sie sie als Umgebungsvariable fest:
```
export CALLER_OBJECT_ID=$(az ad signed-in-user show --query id --output tsv)
```
Weisen Sie sich selbst die Azure RBAC-Rolle Key Vault Secrets Officer für den Schlüssel mithilfe des Befehls az role assignment create zu.
```
az role assignment create --assignee $CALLER_OBJECT_ID \
    --role "Key Vault Secrets Officer" \
    --scope $KEY_VAULT_RESOURCE_ID
```

Erstellen Sie ein Geheimnis im Schlüsseltresor mithilfe des Befehls 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\!"

Weisen Sie der UAMI die Rolle "Benutzer von Key Vault Secrets" mithilfe des az role assignment create Befehls zu.

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

Kommentieren des Dienstkontos

Kommentieren Sie das Servicekonto mit der verwalteten Identitätsmandanten-ID mithilfe des kubectl annotate-Befehls.
```
kubectl annotate sa demo -n demo azure.workload.identity/tenant-id=$MI_TENANT_ID
```
Kommentieren Sie das Servicekonto mit der verwalteten Identitätsclient-ID mithilfe des kubectl annotate-Befehls.
```
kubectl annotate sa demo -n demo azure.workload.identity/client-id=$MI_CLIENT_ID
```

Bereitstellen der Beispielanwendung

Stellen Sie den Beispiel-Pod bereit, der die Identitätsbindung verwendet, um ein Zugriffstoken für die verwaltete Identität abzurufen, um mithilfe des folgenden kubectl apply Befehls auf Azure Key Vault zuzugreifen:

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

Zugriff auf das Key Vault aus der Beispielanwendung überprüfen

Beschreiben Sie den Pod, und bestätigen Sie mithilfe des kubectl describe pod-Befehls, dass Umgebungsvariablen und projizierte Tokenvolumen-Mounts vorhanden sind.
```
kubectl describe pod demo -n demo
```
Die erwartete Ausgabe sollte Werte für AZURE_CLIENT_ID, AZURE_TENANT_ID, AZURE_FEDERATED_TOKEN_FILE, AZURE_AUTHORITY_HOST und AZURE_KUBERNETES_TOKEN_PROXY enthalten. AZURE_KUBERNETES_SNI_NAME und AZURE_KUBERNETES_CA_FILE.
Überprüfen Sie, ob der Pod ein Token abrufen und mithilfe des kubectl logs Befehls auf die Ressource zugreifen kann.
```
kubectl logs demo -n demo
```
Wenn der Vorgang erfolgreich ist, sollte die Ausgabe dem folgenden Beispiel ähneln:
```
I1107 20:03:42.865180       1 main.go:77] "successfully got secret" secret="Hello!"
```

Skalieren von Identitätsbindungen über mehrere Cluster hinweg

Identitätsbindungen ermöglichen das Zuordnen mehrerer AKS-Cluster zum gleichen UAMI, während weiterhin ein einzelnes FIC verwendet wird. Um Identitätsbindungen auf mehrere Cluster zu skalieren, können Sie die Schritte aus dem Erstellen einer Identitätsbindung wiederholen, indem Sie den Zugriff auf den Schlüsseltresor aus der Beispielanwendung für jeden zusätzlichen Cluster überprüfen, den Sie demselben UAMI zuordnen möchten (erstellen einer neuen Identitätsbindung pro Cluster).

Bereinigen von Ressourcen

Wenn Sie die in diesem Artikel erstellten Ressourcen nicht mehr benötigen, können Sie sie bereinigen, um zukünftige Kosten zu vermeiden.

Löschen Sie den Pod mithilfe des kubectl delete pod Befehls.
```
kubectl delete pod demo -n demo
```
Löschen Sie den Namespace mithilfe des kubectl delete ns Befehls.
```
kubectl delete ns demo
```
Löschen Sie die Ressourcengruppe und alle zugehörigen Ressourcen mithilfe des az group delete Befehls.
```
az group delete --name $RESOURCE_GROUP --yes --no-wait
```

Konzepte für Identitätsbindungen

Feedback

War diese Seite hilfreich?

Last updated on 2026-01-28