Bereitstellen und Konfigurieren von Microsoft Entra Workload ID in einem Azure Kubernetes Service (AKS) Cluster

• Terraform lokal installiert. Installationsanweisungen finden Sie unter Install Terraform.
• Die Umgebungsvariable ARM_SUBSCRIPTION_ID wird auf die Abonnement-ID festgelegt, in der Sie die Ressourcen erstellen möchten. AzureRM 4.x erfordert die Abonnement-ID für den Plan und anwenden von Vorgängen.

Erstellen der Terraform-Konfigurationsdatei

Die main.tf Datei enthält Definitionen für den AKS-Cluster, verwaltete Identität, Verbundidentitätsanmeldeinformationen, Azure Key Vault und Kubernetes-Ressourcen, die zum Konfigurieren und Überprüfen von Microsoft Entra Workload ID verwendet werden.

1. Erstellen Sie eine Datei mit dem Namen main.tf, und fügen Sie den folgenden Code hinzu, um die Terraform-Version zu definieren und den Azure Anbieter anzugeben:

   terraform {
    required_version = ">= 1.5.0"
    required_providers {
      azurerm = {
        source  = "hashicorp/azurerm"
        version = "~> 4.0"
      }
      kubernetes = {
        source  = "hashicorp/kubernetes"
        version = "~> 2.30"
      }
      random = {
        source  = "hashicorp/random"
        version = "~> 3.6"
      }
    }
   }
   provider "azurerm" {
    features {}
   }
   data "azurerm_client_config" "current" {}
   

2. Fügen Sie den folgenden Code zu main.tf hinzu, um wiederverwendbare Variablen zu definieren und eindeutige Namen für alle Ressourcen zu generieren.

   resource "random_string" "suffix" {
    length  = 6
    upper   = false
    special = false
    numeric = true
   }
   locals {
    suffix = random_string.suffix.result
    resource_group_name       = "rg-aks-wi-${local.suffix}"
    cluster_name              = "akswi${local.suffix}"
    managed_identity_name     = "uami-wi-${local.suffix}"
    federated_credential_name = "fic-wi-${local.suffix}"
    key_vault_name            = lower(substr("kvwi${local.suffix}", 0, 24))
    secret_name               = "secret-${local.suffix}"
    service_account_name      = "workload-sa-${local.suffix}"
    service_account_namespace = "default"
    workload_identity_subject = "system:serviceaccount:${local.service_account_namespace}:${local.service_account_name}"
   }
   

Erstellen Sie eine Ressourcengruppe mit dem Befehl az group create.

export RANDOM_ID="$(openssl rand -hex 3)"
export RESOURCE_GROUP="myResourceGroup$RANDOM_ID"
export LOCATION="<your-preferred-region>"
az group create --name "${RESOURCE_GROUP}" --location "${LOCATION}"

Fügen Sie dem main.tf den folgenden Code hinzu, um eine Azure Ressourcengruppe zu erstellen. Aktualisieren Sie den Wert location entsprechend Ihrer bevorzugten Azure Region.

resource "azurerm_resource_group" "this" {
 name     = local.resource_group_name
 location = "eastus"
}

Rufen Sie die OIDC-Aussteller-URL mithilfe des az aks show Befehls ab, und speichern Sie sie in einer Umgebungsvariable.

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 und unveränderliche GUID für jeden Cluster handelt.

Fügen Sie den folgenden Code zu main.tf hinzu, um die OIDC-Aussteller-URL abzurufen.

output "oidc_issuer_url" {
 value = azurerm_kubernetes_cluster.this.oidc_issuer_url
}

1. Rufen Sie Ihre Abonnement-ID ab, und speichern Sie sie mithilfe des az account show Befehls in einer Umgebungsvariable.

   export SUBSCRIPTION="$(az account show --query id --output tsv)"
   

2. Erstellen Sie eine benutzerseitig zugewiesene verwaltete Identität mit dem Befehl az identity create.

   export USER_ASSIGNED_IDENTITY_NAME="myIdentity$RANDOM_ID"
   az identity create \
       --name "${USER_ASSIGNED_IDENTITY_NAME}" \
       --resource-group "${RESOURCE_GROUP}" \
       --location "${LOCATION}" \
       --subscription "${SUBSCRIPTION}"
   

   Das folgende Ausgabebeispiel zeigt die erfolgreiche Erstellung einer verwalteten Identität:

   {
     "clientId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
     "id": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourcegroups/myResourceGroupxxxxxx/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myIdentityxxxxxx",
     "location": "eastus",
     "name": "myIdentityxxxxxx",
     "principalId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
     "resourceGroup": "myResourceGroupxxxxxx",
     "systemData": null,
     "tags": {},
     "tenantId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
     "type": "Microsoft.ManagedIdentity/userAssignedIdentities"
   }
   

3. Rufen Sie die Client-ID der verwalteten Identität ab, und speichern Sie sie mithilfe des az identity show Befehls in einer Umgebungsvariable.

   export USER_ASSIGNED_CLIENT_ID="$(az identity show \
       --resource-group "${RESOURCE_GROUP}" \
       --name "${USER_ASSIGNED_IDENTITY_NAME}" \
       --query 'clientId' \
       --output tsv)"
   

Fügen Sie den folgenden Code zu main.tf hinzu, um eine verwaltete Identität zu erstellen.

resource "azurerm_user_assigned_identity" "this" {
 name                = local.managed_identity_name
 location            = azurerm_resource_group.this.location
 resource_group_name = azurerm_resource_group.this.name
}

1. Stellen Sie mithilfe des Befehls az aks get-credentials eine Verbindung mit Ihrem AKS-Cluster her.

   az aks get-credentials --name "${CLUSTER_NAME}" --resource-group "${RESOURCE_GROUP}"
   

2. Erstellen Sie ein Kubernetes-Dienstkonto, und kommentieren Sie es mit der Client-ID der verwalteten Identität, indem Sie das folgende Manifest mithilfe des kubectl apply Befehls anwenden.

   export SERVICE_ACCOUNT_NAME="workload-identity-sa$RANDOM_ID"
   export SERVICE_ACCOUNT_NAMESPACE="default"
   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
   

1. Fügen Sie den folgenden Code zum main.tf Konfigurieren des Kubernetes-Zugriffs hinzu, um die Erstellung von Kubernetes-Ressourcen zu ermöglichen:

   data "azurerm_kubernetes_cluster" "this" {
    name                = azurerm_kubernetes_cluster.this.name
    resource_group_name = azurerm_resource_group.this.name
   }
   provider "kubernetes" {
    host                   = data.azurerm_kubernetes_cluster.this.kube_config[0].host
    client_certificate     = base64decode(data.azurerm_kubernetes_cluster.this.kube_config[0].client_certificate)
    client_key             = base64decode(data.azurerm_kubernetes_cluster.this.kube_config[0].client_key)
    cluster_ca_certificate = base64decode(data.azurerm_kubernetes_cluster.this.kube_config[0].cluster_ca_certificate)
   }
   

2. Fügen Sie den folgenden Code zu main.tf hinzu, um ein Kubernetes-Dienstkonto zu erstellen und mit der Client-ID der verwalteten Identität zu annotieren.

   resource "kubernetes_service_account" "this" {
    metadata {
      name      = local.service_account_name
      namespace = local.service_account_namespace
      annotations = {
        "azure.workload.identity/client-id" = azurerm_user_assigned_identity.this.client_id
      }
    }
   }
   

Erstellen Sie mithilfe des az identity federated-credential create-Befehls federierte Identitätsnachweise zwischen der verwalteten Identität, dem Herausgeber des Dienstkontos und dem Subjekt.

export FEDERATED_IDENTITY_CREDENTIAL_NAME="myFedIdentity$RANDOM_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

Fügen Sie den folgenden Code zu main.tf hinzu, um eine Verbundidentität zwischen der verwalteten Identität, dem Dienstkontoaussteller und dem Subjekt zu erstellen.

resource "azurerm_federated_identity_credential" "this" {
 name                = local.federated_credential_name
 resource_group_name = azurerm_resource_group.this.name
 parent_id           = azurerm_user_assigned_identity.this.id
 issuer              = azurerm_kubernetes_cluster.this.oidc_issuer_url
 subject             = local.workload_identity_subject
 audience            = ["api://AzureADTokenExchange"]
}

1. Erstellen Sie einen Schlüsseltresor mit aktiviertem Bereinigungsschutz und aktivierter Azure RBAC-Autorisierung mithilfe des Befehls az keyvault create. 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 KEYVAULT_NAME="kv-workload-id$RANDOM_ID"
   az keyvault create \
       --name "${KEYVAULT_NAME}" \
       --resource-group "${RESOURCE_GROUP}" \
       --location "${LOCATION}" \
       --enable-purge-protection \
       --enable-rbac-authorization
   

2. Rufen Sie die ID der Schlüsseltresorressource ab und speichern Sie sie mithilfe des az keyvault show Befehls in einer Umgebungsvariable.

   export KEYVAULT_RESOURCE_ID=$(az keyvault show --resource-group "${RESOURCE_GROUP}" \
       --name "${KEYVAULT_NAME}" \
       --query id \
       --output tsv)
   

Fügen Sie den folgenden Code hinzu, um einen Schlüsseltresor mit Löschschutz und aktivierter Azure RBAC-Autorisierung zu main.tf erstellen:

resource "azurerm_key_vault" "this" {
 name                       = local.key_vault_name
 location                   = azurerm_resource_group.this.location
 resource_group_name        = azurerm_resource_group.this.name
 tenant_id                  = data.azurerm_client_config.current.tenant_id
 sku_name                   = "standard"
 enable_rbac_authorization  = true
 purge_protection_enabled   = true
}

1. Rufen Sie die Aufruferobjekt-ID ab, und speichern Sie sie mithilfe des az ad signed-in-user show Befehls in einer Umgebungsvariable.

   export CALLER_OBJECT_ID=$(az ad signed-in-user show --query id -o tsv)
   

2. Weisen Sie sich selbst die rolle Azure RBAC Key Vault Secrets Officer zu, damit Sie mithilfe des Befehls az role assignment create einen geheimen Schlüssel im neuen key vault erstellen können.

   az role assignment create --assignee "${CALLER_OBJECT_ID}" \
       --role "Key Vault Secrets Officer" \
       --scope "${KEYVAULT_RESOURCE_ID}"
   

   Wichtig

   Azure Rollenzuweisungen können bis zu 10 Minuten dauern, bis sie verteilt werden. Wenn das Erstellen des geheimen Schlüssels im nächsten Abschnitt einen 403 Fehler zurückgibt, warten Sie, bis die Rollenzuweisung verteilt wird, und wiederholen Sie dann den Befehl. Weitere Informationen finden Sie unter Troubleshoot Azure RBAC.

Fügen Sie den folgenden Code zu main.tf hinzu, um sich selbst die Azure RBAC-Rolle Key Vault Secrets Officer zuzuweisen, damit Sie ein Secret im neuen Key Vault erstellen und der verwalteten Identität, die vom Benutzer zugewiesen wird, die Rolle Key Vault Secrets User zuweisen können.

resource "azurerm_role_assignment" "user" {
 scope                = azurerm_key_vault.this.id
 role_definition_name = "Key Vault Secrets Officer"
 principal_id         = data.azurerm_client_config.current.object_id
}
resource "azurerm_role_assignment" "identity" {
 scope                = azurerm_key_vault.this.id
 role_definition_name = "Key Vault Secrets User"
 principal_id         = azurerm_user_assigned_identity.this.principal_id
}

1. Erstellen Sie ein Geheimnis im Schlüsseltresor mithilfe des Befehls az keyvault secret set.

   Erstellen Sie einen geheimen Schlüssel, dessen Name in der KEYVAULT_SECRET_NAME Variablen gespeichert ist, und legen Sie dessen Wert Hello! auf den von Ihnen erstellten Schlüsseltresor fest.

   export KEYVAULT_SECRET_NAME="my-secret$RANDOM_ID"
   az keyvault secret set \
       --vault-name "${KEYVAULT_NAME}" \
       --name "${KEYVAULT_SECRET_NAME}" \
       --value 'Hello!'
   

2. Rufen Sie die Prinzipal-ID der vom Benutzer zugewiesenen verwalteten Identität ab, und speichern Sie sie mithilfe des az identity show Befehls in einer Umgebungsvariable.

   export IDENTITY_PRINCIPAL_ID=$(az identity show \
       --name "${USER_ASSIGNED_IDENTITY_NAME}" \
       --resource-group "${RESOURCE_GROUP}" \
       --query principalId \
       --output tsv)
   

3. Weisen Sie die Rolle Key Vault Secrets User der vom Benutzer zugewiesenen verwalteten Identität mithilfe des Befehls az role assignment create zu. Dieser Schritt gibt der verwalteten Identität die Berechtigung, Secrets aus dem Key Vault zu lesen.

   az role assignment create \
       --assignee-object-id "${IDENTITY_PRINCIPAL_ID}" \
       --role "Key Vault Secrets User" \
       --scope "${KEYVAULT_RESOURCE_ID}" \
       --assignee-principal-type ServicePrincipal
   

4. Erstellen Sie eine Umgebungsvariable für die Schlüsseltresor-URL mithilfe des az keyvault show Befehls.

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

Fügen Sie den folgenden Code zu main.tf hinzu, um ein Geheimnis im Schlüsseltresor zu erstellen.

resource "azurerm_key_vault_secret" "this" {
 name         = local.secret_name
 value        = "Hello from Key Vault"
 key_vault_id = azurerm_key_vault.this.id

 depends_on = [azurerm_role_assignment.user]
}

Bereitstellen eines Überprüfungs pods und Testen des Zugriffs (Azure CLI)

1. Stellen Sie einen Pod bereit, um zu überprüfen, ob die Workload-Identität auf das Secret im Key Vault zugreifen kann. Im folgenden Beispiel wird das bild ghcr.io/azure/azure-workload-identity/msal-go verwendet, das eine Beispielanwendung enthält, die einen geheimen Schlüssel aus Azure Key Vault mithilfe von Microsoft Entra Workload ID abruft:

   kubectl apply -f - <<EOF
   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
   

2. Warten Sie mit dem Befehl Ready darauf, dass sich der Pod im kubectl wait-Zustand befindet.

   kubectl wait --namespace ${SERVICE_ACCOUNT_NAMESPACE} --for=condition=Ready pod/sample-workload-identity-key-vault --timeout=120s
   

3. Überprüfen Sie, ob die SECRET_NAME Umgebungsvariable mithilfe des kubectl describe Befehls im Pod festgelegt ist.

   kubectl describe pod sample-workload-identity-key-vault | grep "SECRET_NAME:"
   

   Wenn der Vorgang erfolgreich ist, sollte die Ausgabe dem folgenden Beispiel ähneln:

   SECRET_NAME: ${KEYVAULT_SECRET_NAME}
   

4. Stellen Sie sicher, dass Pods ein Token abrufen und mithilfe des kubectl logs Befehls auf die Ressource zugreifen können.

   kubectl logs sample-workload-identity-key-vault
   

   Wenn der Vorgang erfolgreich ist, sollte die Ausgabe dem folgenden Beispiel ähneln:

   I0114 10:35:09.795900       1 main.go:63] "successfully got secret" secret="Hello!"
   

   Wichtig

   Azure RBAC-Rollenzuweisungen können bis zu 10 Minuten dauern, bis sie verteilt werden. 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 Troubleshoot Azure RBAC.

Deaktivieren von Microsoft Entra Workload ID in einem AKS-Cluster

Um Microsoft Entra Workload ID auf dem AKS-Cluster zu deaktivieren, in dem Sie ihn aktiviert und konfiguriert haben, verwenden Sie den az aks update Befehl mit dem --disable-workload-identity Parameter.

az aks update \
    --resource-group "${RESOURCE_GROUP}" \
    --name "${CLUSTER_NAME}" \
    --disable-workload-identity

Bereitstellen eines Überprüfungs pods (Terraform)

Fügen Sie den folgenden Code zu main.tf hinzu, um einen Überprüfungspod bereitzustellen, der die Workloadidentität verwendet, um auf das Geheimnis im Schlüsseltresor zuzugreifen.

resource "kubernetes_pod" "test" {
 metadata {
   name      = "workload-identity-test"
   namespace = local.service_account_namespace
   labels = {
     "azure.workload.identity/use" = "true"
   }
 }
 spec {
   service_account_name = kubernetes_service_account.this.metadata[0].name
   container {
     name  = "test"
     image = "ghcr.io/azure/azure-workload-identity/msal-go"
     env {
       name  = "KEYVAULT_URL"
       value = azurerm_key_vault.this.vault_uri
     }
     env {
       name  = "SECRET_NAME"
       value = azurerm_key_vault_secret.this.name
     }
   }
 }

 depends_on = [
   azurerm_federated_identity_credential.this,
   azurerm_role_assignment.identity,
 ]
}

Initialisieren Sie Terraform

Initialisieren Sie Terraform im Verzeichnis, das Ihre main.tf Datei enthält, mithilfe des terraform init Befehls. Dieser Befehl lädt den Azure Anbieter herunter, der zum Verwalten von Azure Ressourcen mit Terraform erforderlich ist.

terraform init

Terraform-Ausführungsplan erstellen

Erstellen Sie mit dem Befehl „terraform plan“ einen Terraform-Ausführungsplan. Dieser Befehl zeigt Ihnen die Ressourcen, die Terraform in Ihrem Azure-Abonnement erstellen oder ändern wird.

terraform plan

Terraform-Konfiguration anwenden

Wenden Sie nach der Überprüfung und Bestätigung des Ausführungsplans die Terraform-Konfiguration mit dem terraform apply Befehl an. Dieser Befehl erstellt oder ändert die ressourcen, die in Ihrer main.tf-Datei in Ihrem Azure-Abonnement definiert sind.

terraform apply

Überprüfen Sie die Bereitstellung

1. Stellen Sie mithilfe des Befehls az aks get-credentials eine Verbindung mit Ihrem AKS-Cluster her.

   az aks get-credentials --name <cluster-name> --resource-group <resource-group>
   

2. Überprüfen Sie den Status des Überprüfungs-Pod mit dem Befehl kubectl get pods.

3. Sobald der Pod den Zustand Ready erreicht hat, überprüfen Sie anhand der Pod‑Protokolle, ob er auf das Key‑Vault‑Geheimnis zugreifen kann. Verwenden Sie dazu den Befehl kubectl logs.

   kubectl logs workload-identity-test
   

   Bei erfolgreicher Ausführung ähnelt die Ausgabe dem folgenden Beispiel:

   I0114 10:35:09.795900       1 main.go:63] "successfully got secret" secret="Hello from Key Vault"
   

   Wichtig

   Azure RBAC-Rollenzuweisungen können bis zu 10 Minuten dauern, bis sie verteilt werden. Wenn der Pod nicht auf den geheimen Schlüssel zugreifen kann, warten Sie, bis die Rollenzuweisung verteilt wird, und erstellen Sie dann den Pod mithilfe des terraform apply -replace="kubernetes_pod.test" Befehls neu. Weitere Informationen finden Sie unter Troubleshoot Azure RBAC.