Compartir a través de

Configuración de una identidad de carga de trabajo entre inquilinos en Azure Kubernetes Service (AKS)

  • Artículo

En este artículo, aprenderá a configurar la identidad de carga de trabajo entre inquilinos en Azure Kubernetes Service (AKS). La identidad de carga de trabajo entre inquilinos permite acceder a los recursos de otro inquilino desde el clúster de AKS. En este ejemplo, creará una instancia de Azure Service Bus en un inquilino y le enviará mensajes desde una carga de trabajo que se ejecuta en un clúster de AKS en otro inquilino.

Para más información sobre la identidad de carga de trabajo, consulte Introducción a la identidad de carga de trabajo.

Requisitos previos

  • Dos suscripciones de Azure, cada una en un inquilino independiente. En este artículo, nos referimos a estos como Inquilino A e Inquilino B.

  • CLI de Azure instalada en la máquina local. Si no ha instalado aún la CLI de Azure, consulte Instalación de la CLI de Azure.

  • Entorno del shell de Bash. En este artículo, se utiliza la sintaxis del shell de Bash.

  • Debe tener los siguientes detalles de suscripción:

    • Identificador de inquilino del inquilino A
    • Identificador de suscripción del inquilino A
    • Identificador de inquilino del inquilino B
    • Identificador de suscripción del inquilino B

Importante

Asegúrese de que permanece dentro de la misma ventana de terminal mientras dure este artículo para conservar las variables de entorno establecidas. Si cierra la ventana de terminal, debe volver a establecer las variables de entorno.

Configuración de recursos en el inquilino A

En el inquilino A, va a crear un clúster de AKS con la identidad de carga de trabajo y el emisor de OIDC habilitados. Este clúster se usa para implementar una aplicación que intenta acceder a los recursos del inquilino B.

Inicio de sesión en el inquilino A

  1. Inicie sesión en su suscripción del inquilino A mediante el comando az login.

    # Set environment variable
TENANT_A_ID=<tenant-id>

az login --tenant $TENANT_A_ID

  2. Asegúrese de que está trabajando con la suscripción correcta en el inquilino A mediante el 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

Creación de recursos en el inquilino A

  1. Cree un grupo de recursos en el inquilino A para hospedar el clúster de AKS mediante el 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. Cree un clúster de AKS en el inquilino A con la identidad de carga de trabajo y el emisor de OIDC habilitado mediante el 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

Obtención de la dirección URL del emisor de OIDC del clúster de AKS

  • Obtenga la dirección URL del emisor de OIDC del clúster en el inquilino A mediante el comando az aks show.

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

Configuración de recursos en el inquilino B

En el inquilino B, va a crear una identidad administrada de Azure Service Bus y le asignará permisos para leer y escribir mensajes en el bus de servicio y establecerá la confianza entre la identidad administrada y el clúster de AKS en el inquilino A.

Inicio de sesión en el inquilino B

  1. Cierre sesión en su suscripción del inquilino A mediante el comando az logout.

    az logout

  2. Inicie sesión en su suscripción del inquilino B mediante el comando az login.

    # Set environment variable
TENANT_B_ID=<tenant-id>

az login --tenant $TENANT_B_ID

  3. Asegúrese de que está trabajando con la suscripción correcta en el inquilino B mediante el 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

Creación de recursos en el inquilino B

  1. Cree un grupo de recursos en el inquilino B para hospedar la identidad administrada mediante el 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. Cree una instancia de Service Bus y una cola en el inquilino B mediante los comandos az servicebus namespace create y 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. Cree una identidad administrada asignada por el usuario en el inquilino B mediante el comando 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

Obtención de identificadores de recursos y asignación de permisos en el inquilino B

  1. Obtenga el identificador de entidad de seguridad de la identidad administrada en el inquilino B mediante el 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. Recupere el identificador de cliente de la identidad administrada en el inquilino B mediante el comando az identity show.

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

  3. Obtenga el identificador de recurso del espacio de nombres de Service Bus en el inquilino B mediante el comando az servicebus namespace show.

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

  4. Asigne la identidad administrada en los permisos del inquilino B para leer y escribir mensajes de Service Bus mediante el 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

Establecimiento de confianza entre el clúster de AKS y la identidad administrada

En esta sección, va a crear la credencial de identidad federada necesaria para establecer la confianza entre el clúster de AKS en el inquilino A y la identidad administrada en el inquilino B. Utilice la dirección URL del emisor de OIDC del clúster de AKS en el inquilino A y el nombre de la identidad administrada en el inquilino B.

  • Cree una credencial de identidad federada mediante el 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 es el nombre de la cuenta de servicio de Kubernetes que se crea en el inquilino A más adelante en el artículo. Cuando el pod de la aplicación realiza solicitudes de autenticación, este valor se envía a Microsoft Entra ID como subject en la solicitud de autorización. Microsoft Entra ID determina la idoneidad en función de si este valor coincide con lo que estableció al crear la credencial de identidad federada, por lo que es importante asegurarse de que el valor coincide.

Implementación de una aplicación para enviar mensajes a la cola de Azure Service Bus

En esta sección, va a implementar una aplicación en el clúster de AKS en el inquilino A que envía mensajes a la cola de Azure Service Bus en el inquilino B.

Inicio de sesión en el inquilino A y obtención de las credenciales de AKS

  1. Cierre sesión en su suscripción del inquilino B mediante el comando az logout.

    az logout

  2. Inicie sesión en su suscripción del inquilino A mediante el comando az login.

    az login --tenant $TENANT_A_ID

  3. Asegúrese de que está trabajando con la suscripción correcta en el inquilino A mediante el comando az account set.

    az account set --subscription $TENANT_A_SUBSCRIPTION_ID

  4. Obtenga las credenciales del clúster de AKS en el inquilino A mediante el comando az aks get-credentials.

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

Creación de recursos de Kubernetes para enviar mensajes a la cola de Azure Service Bus

  1. Cree una nueva instancia de la cuenta del servicio Kubernetes en el espacio de nombres default y pase el identificador de cliente de la identidad administrada del inquilino B al comando kubectl apply. El identificador de cliente se usa para autenticar la aplicación del inquilino A a la instancia de Azure Service Bus en el inquilino B.

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

  2. Cree un nuevo trabajo de Kubernetes en el espacio de nombres default para enviar 100 mensajes a la cola de Azure Service Bus. La plantilla del pod está configurada para usar la identidad de carga de trabajo y la cuenta de servicio que creó en el paso anterior. Tenga en cuenta también que la variable de entorno AZURE_TENANT_ID se establece en el identificador de inquilino del inquilino B. Esto es necesario, ya que la identidad de carga de trabajo tiene como valor predeterminado el inquilino del clúster de AKS, por lo que debe establecer explícitamente el identificador de inquilino del inquilino 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

Comprobar la implementación

  1. Compruebe que el pod está configurado correctamente para interactuar con la cola de Azure Service Bus en el inquilino B; para ello, compruebe el estado del pod mediante el 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. Compruebe los registros del pod para ver si la aplicación pudo enviar mensajes entre inquilinos mediante el comando kubectl logs.

    kubectl logs $POD_NAME

    El resultado debería ser similar al ejemplo siguiente:

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

Nota:

Como paso de comprobación adicional, puede ir a Azure Portal y desplazarse a la cola de Azure Service Bus en el inquilino B para ver los mensajes enviados en Service Bus Explorer.

Limpieza de recursos

Después de comprobar que la implementación es correcta, puede limpiar los recursos para evitar incurrir en costos de Azure.

Eliminación de recursos en el inquilino A

  1. Inicie sesión en su suscripción del inquilino A mediante el comando az login.

    az login --tenant $TENANT_A_ID

  2. Asegúrese de que está trabajando con la suscripción correcta en el inquilino A mediante el comando az account set.

    az account set --subscription $TENANT_A_SUBSCRIPTION_ID

  3. Elimine el grupo de recursos de Azure y todos sus recursos mediante el comando az group delete.

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

Eliminación de recursos en el inquilino B

  1. Inicie sesión en su suscripción del inquilino B mediante el comando az login.

    az login --tenant $TENANT_B_ID

  2. Asegúrese de que está trabajando con la suscripción correcta en el inquilino B mediante el comando az account set.

    az account set --subscription $TENANT_B_SUBSCRIPTION_ID

  3. Elimine el grupo de recursos de Azure y todos sus recursos mediante el comando az group delete.

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

Pasos siguientes

En este artículo, ha aprendido a configurar la identidad de carga de trabajo entre inquilinos en Azure Kubernetes Service (AKS). Para obtener más información sobre la identidad de la carga de trabajo, consulte los artículos siguientes: