Freigeben über

Konfigurieren einer mandantenübergreifenden Workloadidentität in Azure Kubernetes Service (AKS)

  • Artikel

In diesem Artikel erfahren Sie, wie Sie die mandantenübergreifende Workloadidentität für Azure Kubernetes Service (AKS) konfigurieren. Mithilfe der mandantenübergreifenden Workloadidentität können Sie über Ihren AKS-Cluster auf Ressourcen in einem anderen Mandanten zugreifen. In diesem Beispiel erstellen Sie einen Azure Service Bus in einem Mandanten und senden Nachrichten von einer Workload, die in einem AKS-Cluster in einem anderen Mandanten ausgeführt wird.

Weitere Informationen zur Workloadidentität finden Sie in der Übersicht über die Workload-Identität.

Voraussetzungen

  • Zwei Azure-Abonnements, jeweils in einem separaten Mandanten. In diesem Artikel beziehen wir uns auf diese mit den Bezeichnungen Mandant A und Mandant B.

  • Azure CLI auf Ihrem lokalen Computer Sollte die Azure CLI noch nicht installiert sein, lesen Sie Installieren der Azure CLI.

  • Bash-Shell-Umgebung In diesem Artikel wird die Bash-Shell-Syntax verwendet.

  • Sie benötigen die folgenden Abonnementdetails:

    • Mandanten-ID von Mandant A
    • Abonnement-ID von Mandant A
    • Mandanten-ID von Mandant B
    • Abonnement-ID von Mandant B

Wichtig

Bleiben Sie für die Dauer der Ausführung dieses Artikels in demselben Terminalfenster, damit die von Ihnen festgelegten Umgebungsvariablen erhalten bleiben. Wenn Sie das Terminalfenster schließen, müssen Sie die Umgebungsvariablen erneut festlegen.

Konfigurieren von Ressourcen in Mandant A

Erstellen Sie in Mandant A einen AKS-Cluster, in dem die Workload-Identität und der OIDC-Aussteller aktiviert sind. Sie verwenden diesen Cluster, um eine Anwendung bereitzustellen, die versucht, auf Ressourcen in Mandant B zuzugreifen.

Anmelden bei Mandant A

  1. Melden Sie sich an Ihrem Mandanten A-Abonnement mit dem Befehl az login an.

    # Set environment variable
TENANT_A_ID=<tenant-id>

az login --tenant $TENANT_A_ID

  2. Vergewissern Sie sich, dass Sie mit dem richtigen Abonnement in Mandant A arbeiten, indem Sie den Befehl az account set verwenden.

    # Set environment variable
TENANT_A_SUBSCRIPTION_ID=<subscription-id>

# Log in to your Tenant A subscription
az account set --subscription $TENANT_A_SUBSCRIPTION_ID

Erstellen von Ressourcen in Mandant A

  1. Erstellen Sie eine Ressourcengruppe in Mandant A, um den AKS-Cluster mithilfe des Befehls az group create zu hosten.

    # Set environment variables
RESOURCE_GROUP=<resource-group-name>
LOCATION=<location>

# Create a resource group
az group create --name $RESOURCE_GROUP --location $LOCATION

  2. Erstellen Sie in Mandant A einen AKS-Cluster mit aktivierter Workload-Identität und OIDC-Aussteller mit dem Befehl az aks create.

    # Set environment variable
CLUSTER_NAME=<cluster-name>

# Create an AKS cluster
az aks create \
  --resource-group $RESOURCE_GROUP \
  --name $CLUSTER_NAME \
  --enable-oidc-issuer \
  --enable-workload-identity \
  --generate-ssh-keys

Abrufen der OIDC-Aussteller-URL aus dem AKS-Cluster

  • Rufen Sie die OIDC-Aussteller-URL aus dem Cluster in Mandant A mit dem Befehl az aks show ab.

    OIDC_ISSUER_URL=$(az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query "oidcIssuerProfile.issuerUrl" --output tsv)

Konfigurieren von Ressourcen in Mandant B

In Mandant B erstellen Sie einen Azure Service Bus, eine verwaltete Identität und weisen ihr die Berechtigung zu, Nachrichten im Service Bus zu lesen und zu schreiben, und stellen das Vertrauen zwischen der verwalteten Identität und dem AKS-Cluster in Mandant A her.

Anmelden bei Mandant B

  1. Melden Sie sich von Ihrem Mandant A-Abonnement mit dem Befehl az logout ab.

    az logout

  2. Melden Sie sich an Ihrem Mandanten B-Abonnement mit dem Befehl az login an.

    # Set environment variable
TENANT_B_ID=<tenant-id>

az login --tenant $TENANT_B_ID

  3. Vergewissern Sie sich, dass Sie mit dem richtigen Abonnement in Mandant B arbeiten, indem Sie den Befehl az account set verwenden.

    # Set environment variable
TENANT_B_SUBSCRIPTION_ID=<subscription-id>

# Log in to your Tenant B subscription
az account set --subscription $TENANT_B_SUBSCRIPTION_ID

Erstellen von Ressourcen in Mandant B

  1. Erstellen Sie eine Ressourcengruppe in Mandant B, um die verwaltete Identität mithilfe des Befehls az group create zu hosten.

    # Set environment variables
RESOURCE_GROUP=<resource-group-name>
LOCATION=<location>

# Create a resource group
az group create --name $RESOURCE_GROUP --location $LOCATION

  2. Erstellen Sie einen Service Bus und eine Warteschlange in Mandant B mit den Befehlen az servicebus namespace create und az servicebus queue create.

    # Set environment variable
SERVICEBUS_NAME=sb-crosstenantdemo-$RANDOM

# Create a new service bus namespace and and return the service bus hostname
SERVICEBUS_HOSTNAME=$(az servicebus namespace create \
  --name $SERVICEBUS_NAME \
  --resource-group $RESOURCE_GROUP \
  --disable-local-auth \
  --query serviceBusEndpoint \
  --output tsv | sed -e 's/https:\/\///' -e 's/:443\///')

# Create a new queue in the service bus namespace
az servicebus queue create \
  --name myqueue \
  --namespace $SERVICEBUS_NAME \
  --resource-group $RESOURCE_GROUP

  3. Erstellen Sie eine benutzerseitig zugewiesene verwaltete Identität in Mandant B mit dem Befehl az identity create:

    # Set environment variable
IDENTITY_NAME=${SERVICEBUS_NAME}-identity

# Create a user-assigned managed identity
az identity create --resource-group $RESOURCE_GROUP --name $IDENTITY_NAME

Abrufen von Ressourcen-IDs und Zuweisen von Berechtigungen in Mandant B

  1. Rufen Sie die Prinzipal-ID der verwalteten Identität in Mandant B mithilfe des Befehls az identity show ab.

    # Get the user-assigned managed identity principalId
PRINCIPAL_ID=$(az identity show \
  --resource-group $RESOURCE_GROUP \
  --name $IDENTITY_NAME \
  --query principalId \
  --output tsv)

  2. Rufen Sie die Client-ID der verwalteten Identität in Mandant B mithilfe des Befehls az identity show ab.

    CLIENT_ID=$(az identity show \
  --resource-group $RESOURCE_GROUP \
  --name $IDENTITY_NAME \
  --query clientId \
  --output tsv)

  3. Rufen Sie die Ressourcen-ID des Service Bus-Namespace in Mandant B mithilfe des Befehls az servicebus namespace show ab.

    SERVICEBUS_ID=$(az servicebus namespace show \
  --name $SERVICEBUS_NAME \
  --resource-group $RESOURCE_GROUP \
  --query id \
  --output tsv)

  4. Weisen Sie der verwalteten Identität in Mandant B mit dem Befehl az role assignment create Berechtigungen zum Lesen und Schreiben von Service Bus-Nachrichten zu.

    az role assignment create \
  --role "Azure Service Bus Data Owner" \
  --assignee-object-id $PRINCIPAL_ID \
  --assignee-principal-type ServicePrincipal \
  --scope $SERVICEBUS_ID

Einrichten einer Vertrauensstellung zwischen AKS-Cluster und verwalteter Identität

In diesem Abschnitt erstellen Sie die Verbundidentitätsanmeldeinformationen, die zum Einrichten der Vertrauensstellung zwischen dem AKS-Cluster in Mandant A und der verwalteten Identität in Mandant B erforderlich sind. Sie verwenden die OIDC-Aussteller-URL aus dem AKS-Cluster in Mandant A und den Namen der verwalteten Identität in Mandant B.

  • Erstellen Sie mithilfe des Befehls az identity federated-credential create eine Anmeldeinformationen für die Verbundidentität.

    az identity federated-credential create \
  --name $IDENTITY_NAME-$RANDOM \
  --identity-name $IDENTITY_NAME \
  --resource-group $RESOURCE_GROUP \
  --issuer $OIDC_ISSUER_URL \
  --subject system:serviceaccount:default:myserviceaccount

--subject system:serviceaccount:default:myserviceaccount ist der Name des Kubernetes-Dienstkontos, das Sie in Mandant A später im Artikel erstellen. Wenn Ihr Anwendungs-Pod Authentifizierungsanforderungen stellt, wird dieser Wert als subject in der Autorisierungsanforderung an Microsoft Entra ID gesendet. Microsoft Entra ID entscheidet, ob dieser Wert mit dem Wert übereinstimmt, den Sie bei der Erstellung der Berechtigungsnachweise für die Verbundidentität festgelegt haben. Es ist also wichtig, dass der Wert übereinstimmt.

Bereitstellen der Anwendung zum Senden von Nachrichten an die Azure Service Bus-Warteschlange

In diesem Abschnitt stellen Sie eine Anwendung für Ihren AKS-Cluster in Mandant A bereit, die Nachrichten an die Azure Service Bus-Warteschlange in Mandant B sendet.

Anmelden bei Mandant A und Abrufen der AKS-Anmeldeinformationen

  1. Melden Sie sich von Ihrem Mandant B-Abonnement mit dem Befehl az logout ab.

    az logout

  2. Melden Sie sich an Ihrem Mandanten A-Abonnement mit dem Befehl az login an.

    az login --tenant $TENANT_A_ID

  3. Vergewissern Sie sich, dass Sie mit dem richtigen Abonnement in Mandant A arbeiten, indem Sie den Befehl az account set verwenden.

    az account set --subscription $TENANT_A_SUBSCRIPTION_ID

  4. Rufen Sie die Anmeldeinformationen für den AKS-Cluster in Mandant A mit dem Befehl az aks get-credentials ab.

    az aks get-credentials --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME

Erstellen von Kubernetes-Ressourcen zum Senden von Nachrichten an die Azure Service Bus-Warteschlange

  1. Erstellen Sie einen neuen Kubernetes ServiceAccount im Namespace default und übergeben Sie die Client-ID Ihrer verwalteten Identität in Mandant B an den Befehl kubectl apply. Die Client-ID wird zur Authentifizierung der App in Mandant A gegenüber dem Azure Service Bus in Mandant B verwendet.

    kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    azure.workload.identity/client-id: $CLIENT_ID
  name: myserviceaccount
EOF

  2. Erstellen Sie einen neuen Kubernetes-Auftrag im Namespace default, um 100 Nachrichten an Ihre Azure Service Bus-Warteschlange zu senden. Die Pod-Vorlage ist so konfiguriert, dass sie die Workload-Identität und das Servicekonto verwendet, das Sie im vorherigen Schritt erstellt haben. Beachten Sie auch, dass die Umgebungsvariable AZURE_TENANT_ID auf die Mandant-ID von Mandant B festgelegt ist. Dies ist erforderlich, da die Workload-Identität standardmäßig dem Mandanten des AKS-Clusters entspricht, so dass Sie die Mandanten-ID von Mandant B explizit festlegen müssen.

    kubectl apply -f - <<EOF
apiVersion: batch/v1
kind: Job
metadata:
  name: myproducer
spec:
  template:
    metadata:
      labels:
        azure.workload.identity/use: "true"
    spec:
      serviceAccountName: myserviceaccount
      containers:
      - image: ghcr.io/azure-samples/aks-app-samples/servicebusdemo:latest
        name: myproducer
        resources: {}
        env:
        - name: OPERATION_MODE
          value: "producer"
        - name: MESSAGE_COUNT
          value: "100"
        - name: AZURE_SERVICEBUS_QUEUE_NAME
          value: myqueue
        - name: AZURE_SERVICEBUS_HOSTNAME
          value: $SERVICEBUS_HOSTNAME
        - name: AZURE_TENANT_ID
          value: $TENANT_B_ID
      restartPolicy: Never
EOF

Überprüfen der Bereitstellung

  1. Überprüfen Sie, ob der Pod korrekt für die Interaktion mit der Azure Service Bus-Warteschlange in Mandant B konfiguriert ist, indem Sie den Status des Pods mit dem Befehl kubectl describe pod überprüfen.

    # Get the dynamically generated pod name
POD_NAME=$(kubectl get po --selector job-name=myproducer -o jsonpath='{.items[0].metadata.name}')

# Verify the tenant ID environment variable is set for Tenant B
kubectl describe pod $POD_NAME | grep AZURE_TENANT_ID

  2. Prüfen Sie in den Protokollen des Pods, ob die Anwendung mit dem Befehl kubectl logs Nachrichten über Mandanten hinweg senden konnte.

    kubectl logs $POD_NAME

    Ihre Ausgabe sollte in etwa dem folgendem Beispiel entsprechen:

    ...
Adding message to batch: Hello World!
Adding message to batch: Hello World!
Adding message to batch: Hello World!
Sent 100 messages

Hinweis

Als zusätzlichen Überprüfungsschritt können Sie zum Azure-Portal gehen und zur Azure Service Bus-Warteschlange in Mandant B navigieren, um die gesendeten Nachrichten im Service Bus Explorer anzuzeigen.

Bereinigen von Ressourcen

Nachdem Sie überprüft haben, dass die Bereitstellung erfolgreich war, können Sie die Ressourcen bereinigen, um Azure-Kosten zu vermeiden.

Löschen von Ressourcen in Mandant A

  1. Melden Sie sich an Ihrem Mandanten A-Abonnement mit dem Befehl az login an.

    az login --tenant $TENANT_A_ID

  2. Vergewissern Sie sich, dass Sie mit dem richtigen Abonnement in Mandant A arbeiten, indem Sie den Befehl az account set verwenden.

    az account set --subscription $TENANT_A_SUBSCRIPTION_ID

  3. Löschen Sie die Azure-Ressourcengruppe und alle zugehörigen Ressourcen mithilfe des Befehls az group delete.

    az group delete --name $RESOURCE_GROUP --yes --no-wait

Löschen von Ressourcen in Mandant B

  1. Melden Sie sich an Ihrem Mandanten B-Abonnement mit dem Befehl az login an.

    az login --tenant $TENANT_B_ID

  2. Vergewissern Sie sich, dass Sie mit dem richtigen Abonnement in Mandant B arbeiten, indem Sie den Befehl az account set verwenden.

    az account set --subscription $TENANT_B_SUBSCRIPTION_ID

  3. Löschen Sie die Azure-Ressourcengruppe und alle zugehörigen Ressourcen mithilfe des Befehls az group delete.

    az group delete --name $RESOURCE_GROUP --yes --no-wait

Nächste Schritte

In diesem Artikel haben Sie erfahren, wie Sie die mandantenübergreifende Workloadidentität für Azure Kubernetes Service (AKS) konfigurieren. Weitere Informationen zur Workloadidentität finden Sie in den folgenden Artikeln: