Partager via

Configurer une identité de charge de travail entre locataires sur Azure Kubernetes Service (AKS)

  • Article

Dans cet article, vous allez apprendre à configurer une identité de charge de travail entre locataires sur Azure Kubernetes Service (AKS). L’identité de charge de travail entre locataires vous permet d’accéder aux ressources d’un autre locataire à partir de votre cluster AKS. Dans cet exemple, vous créez une instance Azure Service Bus dans un locataire à laquelle vous envoyez des messages à partir d’une charge de travail exécutée dans un cluster AKS dans un autre locataire.

Pour en savoir plus sur les identités de charge de travail, consultez Vue d’ensemble de l’identité de charge de travail.

Prérequis

  • Deux abonnements Azure, chacun dans un locataire distinct. Dans cet article, nous les appelons Locataire A et Locataire B.

  • Azure CLI installé sur votre ordinateur local. Si vous n’avez pas installé Azure CLI, consultez Installer l’interface de ligne de commande Azure.

  • Environnement de l’interpréteur de commandes Bash. Cet article utilise la syntaxe de l’interpréteur de commandes Bash.

  • Vous devez disposer des détails suivants des abonnements :

    • ID du Locataire A
    • ID d’abonnement du Locataire A
    • ID du Locataire B
    • ID d’abonnement du Locataire B

Important

Veillez à rester dans la même fenêtre de terminal pendant la lecture de cet article afin de conserver les variables d’environnement que vous définissez. Si vous fermez la fenêtre de terminal, vous devrez à nouveau définir les variables d’environnement.

Configurer des ressources dans Locataire A

Dans Locataire A, vous créez un cluster AKS avec l’identité de charge de travail et l’émetteur OIDC activés. Vous utilisez ce cluster pour déployer une application qui tente d’accéder aux ressources dans Locataire B.

Se connecter à Locataire A

  1. Connectez-vous à votre abonnement Locataire A à l’aide de la commande az login.

    # Set environment variable
TENANT_A_ID=<tenant-id>

az login --tenant $TENANT_A_ID

  2. Vérifiez que vous utilisez l’abonnement approprié dans Locataire A à l’aide de la commande az account set.

    # Set environment variable
TENANT_A_SUBSCRIPTION_ID=<subscription-id>

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

Créer des ressources dans Locataire A

  1. Créez un groupe de ressources dans Locataire A pour héberger le cluster AKS à l’aide de la commande az group create.

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

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

  2. Dans Locataire A, créez un cluster AKS avec l’identité de charge de travail et l’émetteur OIDC activés à l’aide de la commande 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

Obtenir l’URL de l’émetteur OIDC à partir du cluster AKS

  • Obtenez l’URL de l’émetteur OIDC à partir du cluster dans Locataire A à l’aide de la commande az aks show.

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

Configurer des ressources dans Locataire B

Dans Locataire B, vous créez une instance Azure Service Bus, une identité managée et lui attribuez des autorisations de lecture et d’écriture de messages dans Azure Service Bus. De plus, vous établissez une relation de confiance entre l’identité managée et le cluster AKS dans Locataire A.

Se connecter à Locataire B

  1. Déconnectez-vous de votre abonnement Locataire A à l’aide de la commande az logout.

    az logout

  2. Connectez-vous à votre abonnement Locataire B à l’aide de la commande az login.

    # Set environment variable
TENANT_B_ID=<tenant-id>

az login --tenant $TENANT_B_ID

  3. Vérifiez que vous utilisez l’abonnement approprié dans Locataire B à l’aide de la commande az account set.

    # Set environment variable
TENANT_B_SUBSCRIPTION_ID=<subscription-id>

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

Créer des ressources dans Locataire B

  1. Créez un groupe de ressources dans Locataire B pour héberger l’identité managée à l’aide de la commande az group create.

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

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

  2. Créez une instance Azure Service Bus et une file d’attente dans Locataire B à l’aide des commandes az servicebus namespace create et 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. Créez une identité managée affectée par l’utilisateur dans Locataire B à l’aide de la commande 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

Obtenir des ID de ressource et attribuer des autorisations dans Locataire B

  1. Obtenez l’ID principal de l’identité managée dans Locataire B à l’aide de la commande az identity show.

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

  2. Obtenez l’ID client de l’identité managée dans Locataire B à l’aide de la commande az identity show.

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

  3. Obtenez l’ID de la ressource de l’espace de noms Azure Service Bus dans Locataire B à l’aide de la commande az servicebus namespace show.

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

  4. Attribuez à l’identité managée dans Locataire B des autorisations de lecture et d’écriture des messages Azure Service Bus à l’aide de la commande az role assignment create.

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

Établir une relation de confiance entre le cluster AKS et l’identité managée

Dans cette section, vous allez créer les informations d’identification d’une identité fédérée nécessaires pour établir une relation de confiance entre le cluster AKS dans Locataire A et l’identité managée dans Locataire B. Vous utilisez l’URL de l’émetteur OIDC à partir du cluster AKS dans Locataire A et le nom de l’identité managée dans Locataire B.

  • Créez des informations d’identification d’une identité fédérée à l’aide de la commande az identity federated-credential create.

    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 est le nom du compte de service Kubernetes que vous allez créer dans Locataire A plus tard dans l’article. Lorsque votre pod d’application effectue des demandes d’authentification, cette valeur est envoyée à Microsoft Entra ID en tant que subject dans la demande d’autorisation. Microsoft Entra ID détermine l’éligibilité en fonction de la correspondance entre cette valeur et celle que vous avez définie lors de la création des informations d’identification d’une identité fédérée. Il est donc important de vous assurer que la valeur correspond.

Déployer l’application pour envoyer des messages à la file d’attente Azure Service Bus

Dans cette section, vous allez déployer une application sur votre cluster AKS dans Locataire A qui envoie des messages à la file d’attente Azure Service Bus dans Locataire B.

Se connecter à Locataire A et obtenir les informations d’identification AKS

  1. Déconnectez-vous de votre abonnement Locataire B à l’aide de la commande az logout.

    az logout

  2. Connectez-vous à votre abonnement Locataire A à l’aide de la commande az login.

    az login --tenant $TENANT_A_ID

  3. Vérifiez que vous utilisez l’abonnement approprié dans Locataire A à l’aide de la commande az account set.

    az account set --subscription $TENANT_A_SUBSCRIPTION_ID

  4. Obtenez les informations d’identification du cluster AKS dans Locataire A à l’aide de la commande az aks get-credentials.

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

Créer des ressources Kubernetes pour envoyer des messages à la file d’attente Azure Service Bus

  1. Créez un compte Kubernetes ServiceAccount dans l’espace de noms default et transmettez l’ID client de votre identité managée dans Locataire B à la commande kubectl apply. L’ID client permet d’authentifier l’application dans Locataire A auprès d’Azure Service Bus dans Locataire B.

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

  2. Créez un travail Kubernetes dans l’espace de noms default pour envoyer 100 messages à votre file d’attente Azure Service Bus. Le modèle de pod est configuré pour utiliser l’identité de charge de travail et le compte de service que vous avez créé à l’étape précédente. Notez également que la variable d’environnement AZURE_TENANT_ID est définie sur l’ID du Locataire B. Cela est nécessaire, car l’identité de charge de travail est définie par défaut sur le locataire du cluster AKS. Vous devez donc définir explicitement l’ID du Locataire B.

    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

Vérifier le déploiement

  1. Vérifiez que le pod est correctement configuré pour interagir avec la file d’attente Azure Service Bus dans Locataire B en vérifiant l’état du pod à l’aide de la commande kubectl describe pod.

    # 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. Consultez les journaux du pod pour voir si l’application a pu envoyer des messages entre les locataires à l’aide de la commande kubectl logs.

    kubectl logs $POD_NAME

    Vous devez obtenir un résultat semblable à l’exemple de sortie qui suit :

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

Remarque

En guise d’étape de vérification supplémentaire, vous pouvez accéder au Portail Azure et à la file d’attente Azure Service Bus dans Locataire B pour afficher les messages envoyés dans Service Bus Explorer.

Nettoyer les ressources

Après avoir vérifié que le déploiement est effectué, vous pouvez nettoyer les ressources pour éviter les coûts liés à Azure.

Supprimer des ressources dans Locataire A

  1. Connectez-vous à votre abonnement Locataire A à l’aide de la commande az login.

    az login --tenant $TENANT_A_ID

  2. Vérifiez que vous utilisez l’abonnement approprié dans Locataire A à l’aide de la commande az account set.

    az account set --subscription $TENANT_A_SUBSCRIPTION_ID

  3. Supprimez le groupe de ressources Azure et toutes les ressources qu’il contient à l’aide de la commande az group delete.

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

Supprimer des ressources dans Locataire B

  1. Connectez-vous à votre abonnement Locataire B à l’aide de la commande az login.

    az login --tenant $TENANT_B_ID

  2. Vérifiez que vous utilisez l’abonnement approprié dans Locataire B à l’aide de la commande az account set.

    az account set --subscription $TENANT_B_SUBSCRIPTION_ID

  3. Supprimez le groupe de ressources Azure et toutes les ressources qu’il contient à l’aide de la commande az group delete.

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

Étapes suivantes

Dans cet article, vous avez appris à configurer une identité de charge de travail entre locataires sur Azure Kubernetes Service (AKS). Pour plus d’informations sur l’identité de charge de travail, consultez les articles suivants :