Freigeben über


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.

  1. 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)
    
  2. 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
    
  3. Erstellen eines Geheimnisses im Schlüsseltresor:

    az keyvault secret set --vault-name $KVName --name $KVSecretName --value "Hello!"
    
  4. 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
    
  5. 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)
    
  6. 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.