Konfigurieren der Workloadidentität in einem AKS Edge Essentials-Cluster (Vorschau)
Azure Kubernetes Service (AKS) Edge Essentials ist eine lokale Kubernetes-Implementierung von Azure Kubernetes Service (AKS), die die Ausführung containerisierter Anwendungen im großen Maßstab automatisiert. In diesem Artikel wird beschrieben, wie Sie die folgenden Aufgaben ausführen:
- Erstellen Sie ein Kubernetes-Dienstkonto, und binden Sie es an die azure Managed Identity.
- Erstellen Sie eine Verbundanmeldeinformationen für die verwaltete Identität, um dem OIDC-Aussteller zu vertrauen.
- Stellen Sie Ihre Anwendung bereit.
- Beispiel: Gewähren Sie einem Pod im Cluster Zugriff auf geheime Schlüssel in einem Azure-Schlüsseltresor.
Eine konzeptionelle Übersicht über den Workload-Identitätsverbund finden Sie unter Workload-Identitätsverbund in Azure Arc-fähigen Kubernetes (Vorschau).
Wichtig
Diese Vorschaufeatures sind auf Self-Service-, Opt-In-Basis verfügbar. Vorschauversionen werden „wie besehen“ und „wie verfügbar“ bereitgestellt und sind von Service Level Agreements und der Herstellergarantie ausgeschlossen. Azure Kubernetes Service Edge Essentials Previews werden teilweise vom Kundensupport auf Best-Effort-Basis abgedeckt.
Hinweis
In dieser öffentlichen Vorschau können Sie mit AKS Edge Essentials die Workloadidentität während der erstbereitstellung des Azure IoT Operations-Schnellstartskripts aktivieren. Dieses Feature ist für andere AKS Edge Essentials-Szenarien nicht verfügbar.
Voraussetzungen
Bevor Sie den Workload-Identitätsverbund für einen AKS Edge Essentials-Cluster verwenden, müssen Sie das Azure IoT Operation-Schnellstartskript bereitstellen, wie unter Erstellen und Konfigurieren eines AKS Edge Essentials-Clusters beschrieben, der Azure IoT Operations ausführen kann. Das Skript aktiviert automatisch das Arbeitslastidentitätsverbundfeature im AKS Edge Essentials-Cluster.
Nachdem Sie den AKS Edge Essentials-Cluster bereitgestellt haben, können Sie den folgenden Befehl verwenden, um den Status der Workload-Identitätserweiterung zu überprüfen:
az connectedk8s show -n $aks_cluster_name -g $resource_group_name
# agentState = "Succeeded"
"agentPublicKeyCertificate": "",
"agentVersion": "1.21.10",
"arcAgentProfile": {
"agentAutoUpgrade": "Enabled",
"agentErrors": [],
"agentState": "Succeeded",
"desiredAgentVersion": "",
"systemComponents": null
# oidcIssuerProfile "enabled": true and "issuerUrl" present
"oidcIssuerProfile": {
"enabled": true,
"issuerUrl": "https://oidcdiscovery-{location}-endpoint-1111111111111111.000.azurefd.net/00000000-0000-0000-0000-000000000000/11111111-1111-1111-1111-111111111111/",
# workloadIdentity "enabled": true
"securityProfile": {
"workloadIdentity": {
"enabled": true
In der Azure-Portal können Sie die wiextension
Erweiterung im Abschnitt "Eigenschaften" Ihres Kubernetes-Clusters anzeigen.
Exportieren von Umgebungsvariablen
Um die Schritte zum Konfigurieren der erforderlichen Identitäten zu vereinfachen, definieren die folgenden Schritte Umgebungsvariablen, auf die in den Beispielen in diesem Artikel verwiesen wird. Denken Sie daran, die gezeigten Werte durch Ihre eigenen Werte zu ersetzen:
$AZSubscriptionID = "00000000-0000-0000-0000-000000000000"
$Location = "westeurope"
$resource_group_name = "myResourceGroup"
$aks_cluster_name = "myAKSCluster"
$SERVICE_ACCOUNT_NAMESPACE = "default"
$SERVICE_ACCOUNT_NAME = "workload-identity-sa"
$FedIdCredentialName = "myFedIdentity"
$MSIName = "myIdentity"
# Include these variables to access key vault secrets from a pod in the cluster.
$KVName = "KV-workload-id"
$KVSecretName= "KV-secret"
Speichern der OIDC-Aussteller-URL in einer Umgebungsvariable
Um die OIDC-Aussteller-URL abzurufen und in einer Umgebungsvariable zu speichern, führen Sie den folgenden Befehl aus:
$SERVICE_ACCOUNT_ISSUER =$(az connectedk8s show --n $aks_cluster_name --resource-group $resource_group_name --query "oidcIssuerProfile.issuerUrl" --output tsv)
Schritt 1: Erstellen eines Kubernetes-Dienstkontos und Binden an die azure Managed Identity
Rufen Sie zunächst den Befehl "az identity create " auf, um eine verwaltete Identität zu erstellen:
az identity create --name $MSIName --resource-group $resource_group_name --location $Location --subscription $AZSubscriptionID
Erstellen Sie als Nächstes Variablen für die Client-ID der verwalteten Identität:
$MSIId=$(az identity show --resource-group $resource_group_name --name $MSIName --query 'clientId' --output tsv)
$MSIPrincipalId=$(az identity show --resource-group $resource_group_name --name $MSIName --query 'principalId' --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. Kopieren Sie die folgenden Azure CLI-Befehle, und fügen Sie sie ein:
$yaml = @"
apiVersion: v1
kind: ServiceAccount
metadata:
annotations:
azure.workload.identity/client-id: $MSIId
name: $SERVICE_ACCOUNT_NAME
namespace: $SERVICE_ACCOUNT_NAMESPACE
"@
# Replace variables within the YAML content
$yaml = $yaml -replace '\$MSIId', $MSIId `
-replace '\$SERVICE_ACCOUNT_NAME', $SERVICE_ACCOUNT_NAME `
-replace '\$SERVICE_ACCOUNT_NAMESPACE', $SERVICE_ACCOUNT_NAMESPACE
# Apply the YAML content to Kubernetes
$yaml | kubectl apply -f -
Die folgende Ausgabe zeigt die Arbeitsauslastungsidentität, die erfolgreich erstellt wurde:
serviceaccount/workload-identity-sa created
Schritt 2: Erstellen einer Verbundanmeldeinformationen für die verwaltete Identität, um dem OIDC-Aussteller zu vertrauen
Rufen Sie zum Erstellen der Verbundidentitätsanmeldeinformationen zwischen der verwalteten Identität, dem Emittenten des Dienstkontos und dem Betreff den Befehl "az identity federated-credential create " auf. 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.
# Create a federated credential
az identity federated-credential create --name $FedIdCredentialName --identity-name $MSIName --resource-group $resource_group_name --issuer $SERVICE_ACCOUNT_ISSUER --subject "system:serviceaccount:${SERVICE_ACCOUNT_NAMESPACE}:${SERVICE_ACCOUNT_NAME}"
# Show the federated credential
az identity federated-credential show --name $FedIdCredentialName --resource-group $resource_group_name --identity-name $MSIName
Hinweis
Nachdem Sie eine Verbundidentitäts-Anmeldeinformationen hinzugefügt haben, dauert es einige Sekunden, bis sie verteilt werden. Tokenanforderungen, die unmittelbar danach vorgenommen wurden, können fehlschlagen, bis der Cache aktualisiert wird. Um dieses Problem zu verhindern, sollten Sie nach dem Erstellen der Verbundidentitätsanmeldeinformationen eine kurze Verzögerung hinzufügen.
Schritt 3: 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 und spec\serviceAccountName
die metadata\namespace
Eigenschaften. Achten Sie darauf, ein Image für image
und einen Containernamen für containerName
anzugeben:
$image = "<image>" # Replace <image> with the actual image name
$containerName = "<containerName>" # Replace <containerName> with the actual container name
$yaml = @"
apiVersion: v1
kind: Pod
metadata:
name: sample-quick-start
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
"@
# Replace variables within the YAML content
$yaml = $yaml -replace '\$SERVICE_ACCOUNT_NAMESPACE', $SERVICE_ACCOUNT_NAMESPACE `
-replace '\$SERVICE_ACCOUNT_NAME', $SERVICE_ACCOUNT_NAME
# Apply the YAML configuration
$yaml | kubectl apply -f -
Wichtig
Stellen Sie sicher, dass die Anwendungs pods, die die Workloadidentität verwenden, die Bezeichnung azure.workload.identity/use: "true"
in der Podspezifikation enthalten. Andernfalls schlagen die Pods nach dem Neustart fehl.
Beispiel: Erteilen von Berechtigungen für den Zugriff auf Azure Key Vault
Die Anweisungen in diesem Schritt beschreiben, wie Sie auf geheime Schlüssel, Schlüssel oder Zertifikate in einem Azure-Schlüsseltresor ü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-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:
az keyvault create --name $KVName --resource-group $resource_group_name --location $Location --enable-purge-protection --enable-rbac-authorization # retrieve the key vault ID for role assignment $KVId=$(az keyvault show --resource-group $resource_group_name --name $KVName --query id --output tsv)
Weisen Sie sich selbst die Rolle "RBAC Key Vault Secrets Officer " zu, damit Sie einen Geheimschlüssel im neuen Schlüsseltresor erstellen können. Es kann bis zu fünf Minuten dauern, bis neue Rollenzuweisungen verteilt und vom Autorisierungsserver aktualisiert werden.
az role assignment create --assignee-object-id $MSIPrincipalId --role "Key Vault Secrets Officer" --scope $KVId --assignee-principal-type ServicePrincipal
Erstellen eines Geheimnisses im Schlüsseltresor:
az keyvault secret set --vault-name $KVName --name $KVSecretName --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:
az role assignment create --assignee-object-id $MSIPrincipalId --role "Key Vault Secrets User" --scope $KVId --assignee-principal-type ServicePrincipal
Erstellen einer Umgebungsvariable für die Schlüsseltresor-URL:
$KVUrl=$(az keyvault show --resource-group $resource_group_name --name $KVName --query properties.vaultUri --output tsv)
Stellen Sie einen Pod bereit, der auf das Dienstkonto und die Key Vault-URL verweist:
$yaml = @" apiVersion: v1 kind: Pod metadata: name: sample-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: $KVUrl - name: SECRET_NAME value: $KVSecretName nodeSelector: kubernetes.io/os: linux "@ # Replace variables within the YAML content $yaml = $yaml -replace '\$SERVICE_ACCOUNT_NAMESPACE', $SERVICE_ACCOUNT_NAMESPACE ` -replace '\$SERVICE_ACCOUNT_NAME', $SERVICE_ACCOUNT_NAME ` -replace '\$KVUrl', $KVUrl ` -replace '\$KVSecretName', $KVSecretName # Apply the YAML configuration $yaml | kubectl --kubeconfig $aks_cluster_name apply -f -
Nächste Schritte
In diesem Artikel haben Sie sie so konfiguriert, dass sie zur Authentifizierung mit diesen Anmeldeinformationen eine Workloadidentität zur Vorbereitung auf Anwendungsworkloads verwendet. Jetzt können Sie Ihre Anwendung bereitstellen und konfigurieren, um die Workloadidentität mit der neuesten Version der Azure Identity-Clientbibliothek zu verwenden.