Condividi tramite

Configurare l'identità del carico di lavoro tra tenant nel servizio Azure Kubernetes

  • Articolo

Questo articolo illustra come configurare l'identità del carico di lavoro tra tenant nel servizio Azure Kubernetes. L'identità del carico di lavoro tra tenant consente di accedere alle risorse in un altro tenant dal cluster del servizio Azure Kubernetes. In questo esempio, si crea un bus di servizio di Azure in un tenant e gli si inviano messaggi da un carico di lavoro in esecuzione in un cluster del servizio Azure Kubernetes in un altro tenant.

Per altre informazioni sull'identità del carico di lavoro, vedere Informazioni generali sul carico di lavoro.

Prerequisiti

  • Due sottoscrizioni di Azure, ognuna in un tenant separato. In questo articolo, si fa riferimento a questi elementi come Tenant A e Tenant B.

  • Interfaccia della riga di comando di Azure installata nel computer locale. Se non si è installato l'interfaccia della riga di comando di Azure, vedere Installare l'interfaccia della riga di comando di Azure.

  • Ambiente shell Bash. Questo articolo usa la sintassi della shell Bash.

  • È necessario disporre dei dettagli della sottoscrizione seguenti:

    • Tenant A ID tenant
    • Tenant A ID sottoscrizione
    • Tenant B ID tenant
    • Tenant B ID sottoscrizione

Importante

Assicurarsi di rimanere all'interno della stessa finestra del terminale per tutta la durata di questo articolo per mantenere le variabili di ambiente impostate. Se si chiude la finestra del terminale, è necessario impostare di nuovo le variabili di ambiente.

Configurare le risorse nel Tenant A

Nel Tenant A, si crea un cluster del servizio Azure Kubernetes con l'identità del carico di lavoro e l'autorità di certificazione OIDC abilitate. Questo cluster viene usato per distribuire un'applicazione che tenta di accedere alle risorse nel Tenant B.

Accedere al Tenant A

  1. Accedere alla sottoscrizione del Tenant A usando il comando az login.

    # Set environment variable
TENANT_A_ID=<tenant-id>

az login --tenant $TENANT_A_ID

  2. Assicurarsi di usare la sottoscrizione corretta nel Tenant A tramite il comando 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

Creare risorse nel Tenant A

  1. Creare un gruppo di risorse nel Tenant A per ospitare il cluster del servizio Azure Kubernetes tramite il comando 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. Creare un cluster del servizio Azure Kubernetes nel Tenant A con l'identità del carico di lavoro e l'autorità di certificazione OIDC abilitate tramite il comando 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

Ottenere l'URL dell'autorità di certificazione OIDC dal cluster del servizio Azure Kubernetes

  • Ottenere l'URL dell'autorità di certificazione OIDC dal cluster nel Tenant A tramite il comando az aks show.

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

Configurare le risorse nel Tenant B

Nel Tenant B, si crea un bus di servizio di Azure, un'identità gestita a cui si assegnano le autorizzazioni di lettura e scrittura dei messaggi nel bus di servizio e si stabilisce l'attendibilità tra l'identità gestita e il cluster del servizio Azure Kubernetes nel Tenant A.

Accedere al Tenant B

  1. Disconnettersi dalla sottoscrizione del Tenant A tramite il comando az logout.

    az logout

  2. Accedere alla sottoscrizione del Tenant B tramite il comando az login.

    # Set environment variable
TENANT_B_ID=<tenant-id>

az login --tenant $TENANT_B_ID

  3. Assicurarsi di usare la sottoscrizione corretta nel Tenant B tramite il comando 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

Creare risorse nel Tenant B

  1. Creare un gruppo di risorse nel Tenant B per ospitare l'identità gestita tramite il comando 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. Creare un bus di servizio e una coda nel Tenant B tramite i comandi az servicebus namespace create e 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. Creare un'identità gestita assegnata dall'utente nel Tenant B tramite il comandoaz 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

Ottenere gli ID risorsa e assegnare le autorizzazioni nel Tenant B

  1. Ottenere l'ID entità di sicurezza dell'identità gestita nel Tenant B tramite il comando 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. Ottenere l'ID client dell'identità gestita nel Tenant B tramite il comando az identity show.

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

  3. Ottenere l'ID risorsa dello spazio dei nomi del bus di servizio nel Tenant B tramite il comando az servicebus namespace show.

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

  4. Assegnare all'identità gestita del Tenant B le autorizzazioni di lettura e scrittura dei messaggi del bus di servizio tramite il comando 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

Costituire un trust tra il cluster del servizio Azure Kubernetes e l'identità gestita

In questa sezione, si creano le credenziali di identità federata necessarie per costituire il trust tra il cluster del servizio Azure Kubernetes nel Tenant A e l'identità gestita nel Tenant B. Si usa l'URL dell'autorità di certificazione OIDC dal cluster del servizio Azure Kubernetes nel Tenant A e il nome dell'identità gestita nel Tenant B.

  • Creare una credenziale di identità federata tramite il comando 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 è il nome dell'account del servizio Kubernetes creato nel Tenant A più avanti nell'articolo. Quando il pod dell'applicazione effettua richieste di autenticazione, questo valore viene inviato a Microsoft Entra ID come subject nella richiesta di autorizzazione. Microsoft Entra ID determina l'idoneità in base alla corrispondenza di questo valore con quello impostato al momento della creazione della credenziale di identità federata, pertanto è importante assicurarsi che il valore coincida.

Distribuire l'applicazione per inviare messaggi alla coda del bus di servizio di Azure

In questa sezione, si distribuisce un'applicazione al cluster del servizio Azure Kubernetes nel Tenant A che invia messaggi alla coda del bus di servizio di Azure nel Tenant B.

Accedere al Tenant A e ottenere le credenziali del servizio Azure Kubernetes

  1. Disconnettersi dalla sottoscrizione del Tenant B tramite il comando az logout.

    az logout

  2. Accedere alla sottoscrizione del Tenant A usando il comando az login.

    az login --tenant $TENANT_A_ID

  3. Assicurarsi di usare la sottoscrizione corretta nel Tenant A tramite il comando az account set.

    az account set --subscription $TENANT_A_SUBSCRIPTION_ID

  4. Ottenere le credenziali per il cluster del servizio Azure Kubernetes nel Tenant A tramite il comandoaz aks get-credentials.

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

Creare risorse di Kubernetes per inviare messaggi alla coda del bus di servizio di Azure

  1. Creare un nuovo ServiceAccount Kubernetes nello spazio dei nomi default e passare l'ID client dell'identità gestita nel Tenant B al comando kubectl apply. L'ID client viene usato per autenticare l'app nel Tenant A presso il bus di servizio di Azure nel Tenant B.

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

  2. Creare un nuovo processo Kubernetes nello spazio dei nomi default per inviare 100 messaggi alla coda del bus di servizio di Azure. Il modello Pod è configurato per l'uso dell'identità del carico di lavoro e dell'account del servizio creato nel passaggio precedente. Si noti anche che la variabile di ambiente AZURE_TENANT_ID è impostata sull'ID tenant del Tenant B. Questa operazione è necessaria perché per impostazione predefinita l'identità del carico di lavoro è quella del cluster del servizio Azure Kubernetes, quindi è necessario impostare in modo esplicito l'ID tenant del Tenant 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

Verificare la distribuzione

  1. Verificare che il pod sia configurato correttamente per interagire con la coda del bus di servizio di Azure nel Tenant B controllando lo stato del pod tramite il comando 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. Controllare i log del pod per verificare se l'applicazione è stata in grado di inviare messaggi tra tenant tramite il comando kubectl logs.

    kubectl logs $POD_NAME

    L'output dovrebbe essere simile all'esempio di output seguente:

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

Nota

Come ulteriore fase di verifica, è possibile accedere al portale di Azure e spostarsi nella coda del bus di servizio di Azure nel Tenant B per visualizzare i messaggi inviati in Service Bus Explorer.

Pulire le risorse

Dopo aver verificato che la distribuzione sia avvenuta correttamente, è possibile pulire le risorse per evitare di incorrere nei costi di Azure.

Eliminare le risorse nel Tenant A

  1. Accedere alla sottoscrizione del Tenant A usando il comando az login.

    az login --tenant $TENANT_A_ID

  2. Assicurarsi di usare la sottoscrizione corretta nel Tenant A tramite il comando az account set.

    az account set --subscription $TENANT_A_SUBSCRIPTION_ID

  3. Eliminare il gruppo di risorse di Azure e tutte le risorse in esso contenute tramite il comando az group delete.

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

Eliminare le risorse nel Tenant B

  1. Accedere alla sottoscrizione del Tenant B tramite il comando az login.

    az login --tenant $TENANT_B_ID

  2. Assicurarsi di usare la sottoscrizione corretta nel Tenant B tramite il comando az account set.

    az account set --subscription $TENANT_B_SUBSCRIPTION_ID

  3. Eliminare il gruppo di risorse di Azure e tutte le risorse in esso contenute tramite il comando az group delete.

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

Passaggi successivi

In questo articolo si è appreso come configurare l'identità del carico di lavoro tra tenant nel servizio Azure Kubernetes. Per altre informazioni sull'identità del carico di lavoro, vedere gli articoli seguenti: