Bereitstellen und Konfigurieren einer Workloadidentität in einem Azure Kubernetes Service-Cluster (AKS)
Azure Kubernetes Service (AKS) ist ein verwalteter Kubernetes-Dienst, mit dem Sie schnell Kubernetes-Cluster bereitstellen und verwalten können. In diesem Artikel lernen Sie Folgendes:
- Bereitstellen eines AKS-Clusters mithilfe der Azure CLI mit dem OpenID Connect-Zertifikataussteller und einer Microsoft Entra-Workload-ID
- Erstellen Sie eine Microsoft Entra-Workload-ID und ein Kubernetes-Dienstkonto.
- Konfigurieren der verwalteten Identität für den Tokenverbund
- Bereitstellen der Workload und Überprüfen der Authentifizierung mit der Workloadidentität
- Gewähren Sie optional einem Pod im Cluster Zugriff auf Geheimnisse in einem Azure-Schlüsseltresor.
Für diesen Artikel werden Grundkenntnisse von Kubernetes-Konzepten vorausgesetzt. Weitere Informationen finden Sie unter Grundlegende Kubernetes-Konzepte für Azure Kubernetes Service (AKS). Wenn Sie noch nicht mit der Microsoft Entra-Workload-ID vertraut sind, lesen Sie den folgenden Übersichtsartikel.
Voraussetzungen
- Sollten Sie über kein Azure-Abonnement verfügen, können Sie zunächst ein kostenloses Azure-Konto erstellen.
- Für diesen Artikel ist mindestens Version 2.47.0 der Azure CLI erforderlich. Bei Verwendung von Azure Cloud Shell ist die aktuelle Version bereits installiert.
- Stellen Sie sicher, dass die Identität, die Sie zum Erstellen Ihres Clusters verwenden, über die erforderlichen Mindestberechtigungen verfügt. Weitere Informationen zu Zugriff und Identität für AKS finden Sie unter Zugriffs- und Identitätsoptionen für Azure Kubernetes Service (AKS).
- Wenn Sie über mehrere Azure-Abonnements verfügen, wählen Sie mithilfe des Befehls az account set die ID des Abonnements aus, in dem die Ressourcen fakturiert werden sollen.
Hinweis
Sie können den Dienstconnector verwenden, um einige Schritte automatisch zu konfigurieren. Siehe auch: Tutorial: Herstellen einer Verbindung mit einem Azure-Speicherkonto in Azure Kubernetes Service (AKS) mithilfe des Dienstconnectors und unter Verwendung einer Workloadidentität.
Festlegen des aktiven Abonnements
Legen Sie zunächst Ihr Abonnement als aktuelles aktives Abonnement fest, indem Sie den Befehl az account set aufrufen und Ihre Abonnement-ID übergeben.
az account set --subscription <subscription-id>
Exportieren von Umgebungsvariablen
Um die Schritte zum Konfigurieren der erforderlichen Identitäten zu vereinfachen, werden in den folgenden Schritten Umgebungsvariablen definiert, auf die in den Beispielen in diesem Artikel verwiesen wird. Denken Sie daran, die gezeigten Werte durch Ihre eigenen Werte zu ersetzen:
export RESOURCE_GROUP="myResourceGroup"
export LOCATION="eastus"
export CLUSTER_NAME="myAKSCluster"
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"
# Include these variables to access key vault secrets from a pod in the cluster.
export KEYVAULT_NAME="keyvault-workload-id"
export KEYVAULT_SECRET_NAME="my-secret"
Erstellen einer Ressourcengruppe
Eine Azure-Ressourcengruppe ist eine logische Gruppe, in der Azure-Ressourcen bereitgestellt und verwaltet werden. Wenn Sie eine Ressourcengruppe erstellen, werden Sie zur Angabe eines Speicherorts aufgefordert. An diesem Speicherort werden die Metadaten Ihrer Ressourcengruppe gespeichert. Darüber hinaus werden dort die Ressourcen in Azure ausgeführt, wenn Sie während der Ressourcenerstellung keine andere Region angeben.
Erstellen Sie durch Aufrufen des Befehls az group create eine Ressourcengruppe:
az group create --name "${RESOURCE_GROUP}" --location "${LOCATION}"
Das folgende Ausgabebeispiel zeigt die erfolgreiche Erstellung einer Ressourcengruppe:
{
"id": "/subscriptions/<guid>/resourceGroups/myResourceGroup",
"location": "eastus",
"managedBy": null,
"name": "myResourceGroup",
"properties": {
"provisioningState": "Succeeded"
},
"tags": null
}
Erstellen eines AKS-Clusters
Erstellen Sie einen AKS-Cluster mit dem Befehl az aks create mit dem Parameter --enable-oidc-issuer, um den OIDC-Zertifikataussteller zu aktivieren. Im folgenden Beispiel wird ein Cluster mit einem einzelnen Knoten erstellt:
az aks create \
--resource-group "${RESOURCE_GROUP}" \
--name "${CLUSTER_NAME}" \
--enable-oidc-issuer \
--enable-workload-identity \
--generate-ssh-keys
Nach wenigen Minuten ist die Ausführung des Befehls abgeschlossen, und es werden Informationen zum Cluster im JSON-Format zurückgegeben.
Hinweis
Beim Erstellen eines AKS-Clusters wird automatisch eine zweite Ressourcengruppe erstellt, um die AKS-Ressourcen zu speichern. Weitere Informationen finden Sie unter Warum werden zwei Ressourcengruppen mit AKS erstellt?
Aktualisieren eines vorhandenen AKS-Clusters
Sie können einen AKS-Cluster aktualisieren, um den OIDC-Zertifikataussteller zu verwenden und die Workloadidentität zu aktivieren, indem Sie den Befehl az aks update mit de Parametern --enable-oidc-issuer und --enable-workload-identity aufrufen. Im folgenden Beispiel wird ein vorhandener Cluster aktualisiert:
az aks update \
--resource-group "${RESOURCE_GROUP}" \
--name "${CLUSTER_NAME}" \
--enable-oidc-issuer \
--enable-workload-identity
Abrufen der OIDC-Zertifikataussteller-URL
Um die URL des OIDC-Zertifikatausstellers abzurufen und in einer Umgebungsvariable zu speichern, führen Sie den folgenden Befehl aus:
export AKS_OIDC_ISSUER="$(az aks show --name "${CLUSTER_NAME}" \
--resource-group "${RESOURCE_GROUP}" \
--query "oidcIssuerProfile.issuerUrl" \
--output tsv)"
Die Umgebungsvariable sollte die URL des Zertifikatausstellers enthalten, ähnlich wie im folgenden Beispiel:
https://eastus.oic.prod-aks.azure.com/00000000-0000-0000-0000-000000000000/11111111-1111-1111-1111-111111111111/
Standardmäßig ist der Zertifikataussteller auf die Verwendung der Basis-URL https://{region}.oic.prod-aks.azure.com/{tenant_id}/{uuid}festgelegt, wobei der Wert für {region} mit dem Speicherort übereinstimmt, an dem der AKS-Cluster bereitgestellt wird. Der Wert {uuid} stellt den OIDC-Schlüssel dar, bei dem es sich um eine zufällig generierte GUID für jeden Cluster handelt, der unveränderlich ist.
Erstellen einer verwalteten Identität
Rufen Sie den Befehl az identity create auf, um eine verwaltete Identität zu erstellen.
az identity create \
--name "${USER_ASSIGNED_IDENTITY_NAME}" \
--resource-group "${RESOURCE_GROUP}" \
--location "${LOCATION}" \
--subscription "${SUBSCRIPTION}"
Als Nächstes erstellen wir eine Variable für die Client-ID der verwalteten Identität.
export USER_ASSIGNED_CLIENT_ID="$(az identity show \
--resource-group "${RESOURCE_GROUP}" \
--name "${USER_ASSIGNED_IDENTITY_NAME}" \
--query 'clientId' \
--output tsv)"
Erstellen eines Kubernetes-Dienstkontos
Erstellen Sie ein Kubernetes-Dienstkonto, und kommentieren Sie es mit der Client-ID der verwalteten Identität, die Sie im vorherigen Schritt erstellt haben. 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 "${CLUSTER_NAME}" --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 zeigt die erfolgreiche Erstellung der Workloadidentität:
serviceaccount/workload-identity-sa created
Erstellen von Anmeldeinformationen für eine Verbundidentität
Erstellen Sie mit dem Befehl az identity federated-credential create die Anmeldeinformationen für die Verbundidentität zwischen der verwalteten Identität, dem Dienstkontoaussteller und dem Antragsteller. Weitere Informationen zu Anmeldeinformationen für eine Verbundidentität in Microsoft Entra finden Sie unter Übersicht über die Anmeldeinformationen für Verbundidentitäten in Microsoft Entra 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
Hinweis
Es dauert einige Sekunden, bis die Anmeldeinformationen für die Verbundidentität nach dem Hinzufügen weitergegeben werden. Wenn eine Tokenanforderung unmittelbar nach dem Hinzufügen der Anmeldeinformationen für die Verbundidentität erfolgt, schlägt die Anforderung möglicherweise fehl, bis der Cache aktualisiert 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 Anwendung
Wenn Sie Ihre Anwendungspods bereitstellen, sollte das Manifest auf das Dienstkonto verweisen, das im Schritt Erstellen eines Kubernetes-Dienstkontos erstellt wurde. Das folgende Manifest zeigt, wie auf das Konto verwiesen wird, insbesondere auf die Eigenschaften metadata\namespace und spec\serviceAccountName. Achten Sie darauf, ein Image für <image> und einen Containernamen für <containerName> anzugeben:
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
name: sample-workload-identity
namespace: ${SERVICE_ACCOUNT_NAMESPACE}
labels:
azure.workload.identity/use: "true" # Required. Only pods with this label can use workload identity.
spec:
serviceAccountName: ${SERVICE_ACCOUNT_NAME}
containers:
- image: <image>
name: <containerName>
EOF
Wichtig
Stellen Sie sicher, dass die Anwendungspods, die die Workloadidentität verwenden, die Bezeichnung azure.workload.identity/use: "true" in der Podspezifikation enthalten. Andernfalls schlagen die Pods nach dem Neustart fehl.
Erteilen von Berechtigungen für den Zugriff auf Azure Key Vault
Die Anweisungen in diesem Schritt zeigen, wie Sie über den Pod auf Geheimnisse, Schlüssel oder Zertifikate in einem Azure-Schlüsseltresor 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-Berechtigungsmodell für die rollenbasierte Zugriffssteuerung (Azure RBAC) 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 Gewähren der Berechtigung zum Zugreifen auf einen Azure-Schlüsseltresor für Anwendungen mit Azure RBAC.
Erstellen Sie einen neuen Schlüsseltresor mit aktiviertem Löschschutz und aktivierter RBAC-Autorisierung. Sie können auch einen vorhandenen Schlüsseltresor verwenden, wenn er sowohl für den Löschschutz als auch für die RBAC-Autorisierung konfiguriert ist:
export KEYVAULT_RESOURCE_GROUP="myResourceGroup" export KEYVAULT_NAME="myKeyVault" az keyvault create \ --name "${KEYVAULT_NAME}" \ --resource-group "${KEYVAULT_RESOURCE_GROUP}" \ --location "${LOCATION}" \ --enable-purge-protection \ --enable-rbac-authorizationWeisen Sie sich selbst die RBAC-Rolle Key Vault-Geheimnisbeauftragter zu, damit Sie ein Geheimnis im neuen Schlüsseltresor erstellen können:
export KEYVAULT_RESOURCE_ID=$(az keyvault show --resource-group "${KEYVAULT_RESOURCE_GROUP}" \ --name "${KEYVAULT_NAME}" \ --query id \ --output tsv) az role assignment create --assignee "\<user-email\>" \ --role "Key Vault Secrets Officer" \ --scope "${KEYVAULT_RESOURCE_ID}"Erstellen eines Geheimnisses im Schlüsseltresor:
export KEYVAULT_SECRET_NAME="my-secret" az keyvault secret set \ --vault-name "${KEYVAULT_NAME}" \ --name "${KEYVAULT_SECRET_NAME}" \ --value "Hello\!"Weisen Sie die Rolle Key Vault-Geheimnisbenutzer der zuvor erstellten benutzerseitig zugewiesenen verwalteten Identität zu. Dieser Schritt gewährt der verwalteten Identität die Berechtigung zum Lesen von Geheimnissen aus dem Schlüsseltresor:
export IDENTITY_PRINCIPAL_ID=$(az identity show \ --name "${USER_ASSIGNED_IDENTITY_NAME}" \ --resource-group "${RESOURCE_GROUP}" \ --query principalId \ --output tsv) az role assignment create \ --assignee-object-id "${IDENTITY_PRINCIPAL_ID}" \ --role "Key Vault Secrets User" \ --scope "${KEYVAULT_RESOURCE_ID}" \ --assignee-principal-type ServicePrincipalErstellen einer Umgebungsvariable für die Schlüsseltresor-URL:
export KEYVAULT_URL="$(az keyvault show \ --resource-group ${KEYVAULT_RESOURCE_GROUP} \ --name ${KEYVAULT_NAME} \ --query properties.vaultUri \ --output tsv)"Stellen Sie einen Pod bereit, der auf das Dienstkonto und die Key Vault-URL verweist:
cat <<EOF | kubectl apply -f - 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
Um zu überprüfen, ob vom Webhook alle Eigenschaften ordnungsgemäß eingefügt werden, verwenden Sie den Befehl kubectl describe:
kubectl describe pod sample-workload-identity-key-vault | grep "SECRET_NAME:"
Bei Erfolg sollte die Ausgabe dem folgenden Beispiel ähneln:
SECRET_NAME: ${KEYVAULT_SECRET_NAME}
Um zu überprüfen, ob der Pod ein Token abrufen und auf die Ressource zugreifen kann, verwenden Sie den Befehl „kubectl logs“:
kubectl logs sample-workload-identity-key-vault
Bei Erfolg sollte die Ausgabe dem folgenden Beispiel ähneln:
I0114 10:35:09.795900 1 main.go:63] "successfully got secret" secret="Hello\\!"
Wichtig
Die Weitergabe von Azure RBAC-Rollenzuweisungen kann bis zu zehn Minuten dauern. Wenn der Pod nicht auf das Geheimnis zugreifen kann, müssen Sie möglicherweise warten, bis die Rollenzuweisung weitergegeben ist. Weitere Informationen finden Sie unter Behandeln von Problemen bei Azure RBAC.
Deaktivieren der Workloadidentität
Um die Microsoft Entra-Workload-ID in dem AKS-Cluster zu deaktivieren, in dem sie aktiviert und konfiguriert wurde, können Sie den folgenden Befehl ausführen:
az aks update \
--resource-group "${RESOURCE_GROUP}" \
--name "${CLUSTER_NAME}" \
--disable-workload-identity
Nächste Schritte
In diesem Artikel haben Sie einen Kubernetes-Cluster bereitgestellt und so konfiguriert, dass eine Workloadidentität zum Vorbereiten auf Anwendungsworkloads verwendet wird, um sich mit diesen Anmeldeinformationen zu authentifizieren. Jetzt können Sie Ihre Anwendung bereitstellen und konfigurieren, um die Workloadidentität mit der neuesten Version der Azure Identity-Clientbibliothek zu verwenden. Wenn Sie Ihre Anwendung nicht neu schreiben können, um die neueste Clientbibliotheksversion zu verwenden, können Sie Ihren Anwendungspod so einrichten, dass die Authentifizierung mithilfe der verwalteten Identität mit einer Workloadidentität als kurzfristige Migrationslösung durchgeführt wird.
Die Dienstconnector-Integration vereinfacht die Verbindungskonfiguration für AKS-Workloads und Azure-Sicherungsdienste. Sie verarbeitet Authentifizierungs- und Netzwerkkonfigurationen auf sichere Weise und folgt bewährten Methoden für die Verbindung mit Azure-Diensten. Weitere Informationen finden Sie unter Herstellen einer Verbindung mit Azure OpenAI Service in AKS mit der Workloadidentität und Einführung in den Dienstconnector.
Azure Kubernetes Service
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für