Bereitstellen und Konfigurieren der Workload-Identität auf einem von Azure Arc-Cluster aktivierten AKS (Vorschau)

Artikel
11/23/2024

Gilt für: Azure Local, Version 23H2

Mithilfe des Workload-Identitätsverbunds können Sie eine vom Benutzer zugewiesene verwaltete Identität oder App-Registrierung in Microsoft Entra-ID so konfigurieren, dass Token von einem externen Identitätsanbieter (IdP) wie Kubernetes als vertrauenswürdig verwendet werden, sodass der Zugriff auf Ressourcen ermöglicht wird, die von Microsoft Entra geschützt sind, z. B. Azure Key Vault oder Azure Blob Storage.

Azure Kubernetes Service (AKS), der von Azure Arc aktiviert ist, ist ein verwalteter Kubernetes-Dienst, mit dem Sie auf einfache Weise Workloads-fähige Kubernetes-Cluster bereitstellen können. In diesem Artikel wird beschrieben, wie Sie die folgenden Aufgaben ausführen:

Erstellen Sie einen AKS Arc-Cluster mit aktivierter Workloadidentität (Vorschau).
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.

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, aktiviert durch Azure Arc Previews, werden teilweise vom Kundensupport auf Best-Effort-Basis abgedeckt.

Hinweis

In der öffentlichen Vorschau unterstützt AKS auf Azure Stack HCI die Aktivierung der Workloadidentität während der AKS-Clustererstellung. Das Aktivieren der Workload-Identität nach der Clustererstellung oder -deaktivierung wird jedoch zurzeit nicht unterstützt.

Voraussetzungen

Bevor Sie einen Kubernetes-Cluster mit aktiviertem Azure Arc bereitstellen, müssen Sie über die folgenden Voraussetzungen verfügen:

Wenn Sie kein Azure-Abonnement haben, erstellen Sie ein kostenloses Azure-Konto, bevor Sie beginnen.
Dieser Artikel erfordert Version 1.4.23 oder höher der Azure CLI. Bei Verwendung von Azure Cloud Shell ist die aktuelle Version bereits installiert.

Exportieren von Umgebungsvariablen

Zur Vereinfachung der Schritte zum Konfigurieren der erforderlichen Identitäten definieren die folgenden Befehle Umgebungsvariablen, auf die in den Beispielen in diesem Artikel verwiesen wird. Ersetzen Sie die folgenden Werte durch eigene Werte:

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

# To access key vault secrets from a pod in the cluster, include these variables:
$KVName = "KV-workload-id" 
$KVSecretName= "KV-secret"

Festlegen des aktiven Abonnements

Legen Sie zunächst Ihr Abonnement als aktuelles aktives Abonnement fest. Führen Sie den Befehl "az account set " mit Ihrer Abonnement-ID aus:

az login  
az account set -s $AZSubscriptionID

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.

Führen Sie den Befehl az group create aus, um eine Ressourcengruppe zu erstellen:

az group create --name $resource_group_name --location $Location

Die folgende Beispielausgabe zeigt die erfolgreiche Erstellung einer Ressourcengruppe:

{ 
  "id": "/subscriptions/<guid>/resourceGroups/myResourceGroup", 
  "location": "westeurope", 
  "managedBy": null, 
  "name": "$resource_group_name", 
  "properties": { 
    "provisioningState": "Succeeded" 
  }, 
  "tags": null 
}

Schritt 1: Erstellen eines AKS Arc-Clusters mit aktivierter Workloadidentität

Um einen AKS Arc-Cluster zu erstellen, benötigen Sie sowohl die Werte $logicnet_Id als auch die $customlocation_ID Werte.

$customlocation_ID: Die Azure Resource Manager-ID des benutzerdefinierten Speicherorts. Der benutzerdefinierte Speicherort wird während der Azure Stack HCI-Clusterbereitstellung konfiguriert. Ihr Infrastrukturadministrator sollte Ihnen die Ressourcen-Manager-ID des benutzerdefinierten Speicherorts geben. Sie können auch die Ressourcen-Manager-ID verwenden $customlocation_ID = $(az customlocation show --name "<your-custom-location-name>" --resource-group $resource_group_name --query "id" -o tsv), wenn der Infrastrukturadministrator einen benutzerdefinierten Standortnamen und Ressourcengruppennamen bereitstellt.
$logicnet_Id: Die Azure Resource Manager-ID des logischen Azure-Netzwerks, das mit den folgenden Schritten erstellt wurde. Ihr Infrastrukturadministrator sollte Ihnen die Ressourcen-Manager-ID des logischen Netzwerks geben. Sie können auch die Ressourcen-Manager-ID verwenden $logicnet_Id = $(az stack-hci-vm network lnet show --name "<your-lnet-name>" --resource-group $resource_group_name --query "id" -o tsv), wenn der Infrastrukturadministrator einen logischen Netzwerknamen und Ressourcengruppennamen bereitstellt.

Führen Sie den Az aksarc-Erstellungsbefehl mit dem --enable-oidc-issuer --enable-workload-identity Parameter aus. Stellen Sie Ihre entra-admin-group-object-ids bereit, und stellen Sie sicher, dass Sie Mitglied der Microsoft Entra ID-Administratorgruppe für den Proxymoduszugriff sind:

az aksarc create  
-n $aks_cluster_name -g $resource_group_name  
--custom-location $customlocation_ID --vnet-ids $logicnet_Id  
--aad-admin-group-object-ids <entra-admin-group-object-ids> 
--generate-ssh-keys  
--enable-oidc-issuer --enable-workload-identity

Nach wenigen Minuten ist die Ausführung des Befehls abgeschlossen, und es werden Informationen zum Cluster im JSON-Format zurückgegeben.

Es kann einige Zeit dauern, bis die Workloadidentitätserweiterung bereitgestellt wird, nachdem ein bereitgestellter Cluster erfolgreich erstellt wurde. Verwenden Sie den folgenden Befehl, um den Status der Workloadidentitä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/"}

Im Azure-Portal können Sie die Wiextension-Erweiterung im Abschnitt "Eigenschaften" Ihres Kubernetes-Clusters anzeigen.

Wichtig

Im Rahmen der Sicherheitsverbesserung für AKS Arc-Cluster löst die Workload-Identitätsaktivierung zwei Änderungen aus. Zunächst dreht sich der Kubernetes-Dienstkontosignaturschlüssel automatisch alle 45 Tage und bleibt 90 Tage gültig. Zweitens ist die --service-account-extend-token-expiration Kennzeichnung deaktiviert, wodurch die Gültigkeit des Tokens von einem Jahr auf maximal 24 Stunden reduziert wird.

Speichern der OIDC-Aussteller-URL in einer Umgebungsvariable

Nachdem der AKS-Cluster erfolgreich erstellt wurde, können Sie die OIDC-Aussteller-URL abrufen und in einer Umgebungsvariable 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 2: Erstellen eines Kubernetes-Dienstkontos und Binden an die verwaltete Azure-Identität

Erstellen Sie zunächst eine verwaltete Identität. Führen Sie den Befehl "az identity create" aus :

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 im vorherigen Schritt erstellt wurde:

az connectedk8s proxy -n $aks_cluster_name -g $resource_group_name

Öffnen Sie ein neues Fenster. Kopieren Sie die folgenden 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 "@ $yaml = $yaml -replace '\$MSIId', $MSIId ` -replace '\$SERVICE_ACCOUNT_NAME', $SERVICE_ACCOUNT_NAME ` -replace '\$SERVICE_ACCOUNT_NAMESPACE', $SERVICE_ACCOUNT_NAMESPACE $yaml | kubectl apply -f -

Die folgende Ausgabe zeigt die erfolgreiche Erstellung des Dienstkontos:

serviceaccount/workload-identity-sa created

Schritt 3: Erstellen einer Verbundanmeldeinformationen für die verwaltete Identität, um dem OIDC-Aussteller zu vertrauen

Erstellen Sie zunächst eine Verbundidentitäts-Anmeldeinformationen. 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.

# 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 4: Bereitstellen Ihrer 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 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.

Freigeben über

Bereitstellen und Konfigurieren der Workload-Identität auf einem von Azure Arc-Cluster aktivierten AKS (Vorschau)

Voraussetzungen

Exportieren von Umgebungsvariablen

Festlegen des aktiven Abonnements

Erstellen einer Ressourcengruppe

Schritt 1: Erstellen eines AKS Arc-Clusters mit aktivierter Workloadidentität

Speichern der OIDC-Aussteller-URL in einer Umgebungsvariable

Schritt 2: Erstellen eines Kubernetes-Dienstkontos und Binden an die verwaltete Azure-Identität

Erstellen eines Kubernetes-Dienstkontos

Schritt 3: Erstellen einer Verbundanmeldeinformationen für die verwaltete Identität, um dem OIDC-Aussteller zu vertrauen

Schritt 4: Bereitstellen Ihrer Anwendung

Beispiel: Erteilen von Berechtigungen für den Zugriff auf Azure Key Vault

Nächste Schritte

Feedback

Zusätzliche Ressourcen