Поделиться через

Настройка удостоверения рабочей нагрузки между клиентами в Служба Azure Kubernetes (AKS)

  • Статья

В этой статье описано, как настроить удостоверение рабочей нагрузки между клиентами в Служба Azure Kubernetes (AKS). Удостоверение рабочей нагрузки между клиентами позволяет получить доступ к ресурсам в другом клиенте из кластера AKS. В этом примере вы создадите Служебная шина Azure в одном клиенте и отправляете в него сообщения из рабочей нагрузки, работающей в кластере AKS в другом клиенте.

Дополнительные сведения об удостоверениях рабочей нагрузки см. в обзоре удостоверений рабочей нагрузки.

Необходимые компоненты

  • Две подписки Azure, каждая из которых содержит отдельный клиент. В этой статье мы называем их клиентом A и клиентом B.

  • Azure CLI, установленная на локальном компьютере. Если у вас нет установленного Интерфейса командной строки Azure, см . статью "Установка Azure CLI".

  • Среда оболочки Bash. В этой статье используется синтаксис оболочки Bash.

  • У вас должны быть следующие сведения о подписке:

    • Идентификатор клиента A
    • Идентификатор подписки клиента
    • Идентификатор клиента B
    • Идентификатор подписки B клиента B

Внимание

Убедитесь, что вы остаетесь в одном окне терминала в течение этой статьи, чтобы сохранить заданные переменные среды. Если закрыть окно терминала, необходимо снова задать переменные среды.

Настройка ресурсов в клиенте A

В клиенте A создается кластер AKS с включенным удостоверением рабочей нагрузки и издателем OIDC. Этот кластер используется для развертывания приложения, пытающегося получить доступ к ресурсам в клиенте B.

Вход в клиент A

  1. Войдите в подписку Tenant A с помощью az login команды.

    # Set environment variable
TENANT_A_ID=<tenant-id>

az login --tenant $TENANT_A_ID

  2. Убедитесь, что вы работаете с правильной подпиской в клиенте A с помощью 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

Создание ресурсов в клиенте A

  1. Создайте группу ресурсов в клиенте A , чтобы разместить кластер AKS с помощью 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. Создайте кластер AKS в клиенте A с удостоверением рабочей нагрузки и издателем OIDC, включенным 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

Получение URL-адреса издателя OIDC из кластера AKS

  • Получите URL-адрес издателя OIDC из кластера в клиенте az aks show A с помощью команды.

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

Настройка ресурсов в клиенте B

В клиенте B вы создаете Служебная шина Azure, управляемое удостоверение и назначаете ему разрешения на чтение и запись сообщений в служебную шину и устанавливаете доверие между управляемым удостоверением и кластером AKS в клиенте A.

Вход в клиент B

  1. Выйдите из подписки Tenant A с помощью az logout команды.

    az logout

  2. Войдите в подписку Tenant B с помощью az login команды.

    # Set environment variable
TENANT_B_ID=<tenant-id>

az login --tenant $TENANT_B_ID

  3. Убедитесь, что вы работаете с правильной подпиской в клиенте B с помощью 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

Создание ресурсов в клиенте B

  1. Создайте группу ресурсов в клиенте B для размещения управляемого удостоверения с помощью 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. Создайте служебную шину и очередь в клиенте B с помощью az servicebus namespace create команд и 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. Создайте управляемое удостоверение, назначаемое пользователем, в клиенте B с помощью 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

Получение идентификаторов ресурсов и назначение разрешений в клиенте B

  1. Получите идентификатор субъекта управляемого удостоверения в клиенте B с помощью 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. Получите идентификатор клиента управляемого удостоверения в клиенте B с помощью az identity show команды.

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

  3. Получите идентификатор ресурса пространства имен служебной шины в клиенте B с помощью az servicebus namespace show команды.

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

  4. Назначьте управляемое удостоверение в клиенте B разрешения на чтение и запись сообщений служебной 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

Установка доверия между кластером AKS и управляемым удостоверением

В этом разделе описано, как создать учетные данные федеративного удостоверения, необходимые для установления доверия между кластером AKS в клиенте A и управляемым удостоверением в клиенте B. Вы используете URL-адрес издателя OIDC из кластера AKS в клиенте A и имя управляемого удостоверения в клиенте B.

  • Создайте учетные данные федеративного 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 — это имя учетной записи службы Kubernetes, создаваемой в клиенте A далее в этой статье. Когда модуль pod приложения выполняет запросы на проверку подлинности, это значение отправляется в идентификатор Microsoft Entra в качестве subject запроса авторизации. Идентификатор Microsoft Entra определяет, соответствует ли это значение заданному при создании учетных данных федеративного удостоверения, поэтому важно убедиться, что значение совпадает.

Развертывание приложения для отправки сообщений в очередь Служебная шина Azure

В этом разделе описано, как развернуть приложение в кластере AKS в клиенте A, который отправляет сообщения в очередь Служебная шина Azure в клиенте B.

Вход в клиент A и получение учетных данных AKS

  1. Выйдите из подписки Клиента B с помощью az logout команды.

    az logout

  2. Войдите в подписку Tenant A с помощью az login команды.

    az login --tenant $TENANT_A_ID

  3. Убедитесь, что вы работаете с правильной подпиской в клиенте A с помощью az account set команды.

    az account set --subscription $TENANT_A_SUBSCRIPTION_ID

  4. Получите учетные данные для кластера AKS в клиенте az aks get-credentials A с помощью команды.

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

Создание ресурсов Kubernetes для отправки сообщений в очередь Служебная шина Azure

  1. Создайте новую службу Kubernetes ServiceAccount в default пространстве имен и передайте идентификатор клиента управляемого удостоверения в клиентЕ B kubectl apply в команду. Идентификатор клиента используется для проверки подлинности приложения в клиенте A в Служебная шина Azure в клиенте B.

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

  2. Создайте новое задание Kubernetes в пространстве имен, чтобы отправить 100 сообщений в default очередь Служебная шина Azure. Шаблон Pod настроен для использования удостоверения рабочей нагрузки и учетной записи службы, созданной на предыдущем шаге. Кроме того, обратите внимание, что AZURE_TENANT_ID переменная среды имеет идентификатор клиента B. Это необходимо в качестве идентификатора рабочей нагрузки по умолчанию для клиента кластера AKS, поэтому необходимо явно задать идентификатор клиента 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

Проверка развертывания

  1. Убедитесь, что модуль pod правильно настроен для взаимодействия с очередью Служебная шина Azure в клиенте B, проверив состояние модуля pod с помощью 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. Проверьте журналы pod, чтобы узнать, удалось ли приложению отправлять сообщения между клиентами с помощью kubectl logs команды.

    kubectl logs $POD_NAME

    Выходные данные должны выглядеть примерно так:

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

Примечание.

В качестве дополнительного шага проверки можно перейти к портал Azure и перейти к очереди Служебная шина Azure в клиенте B, чтобы просмотреть сообщения, отправленные в обозревателе служебная шина.

Очистка ресурсов

Убедившись, что развертывание выполнено успешно, можно очистить ресурсы, чтобы избежать затрат Azure.

Удаление ресурсов в клиенте A

  1. Войдите в подписку Tenant A с помощью az login команды.

    az login --tenant $TENANT_A_ID

  2. Убедитесь, что вы работаете с правильной подпиской в клиенте A с помощью az account set команды.

    az account set --subscription $TENANT_A_SUBSCRIPTION_ID

  3. Удалите группу ресурсов Azure и все ресурсы в ней az group delete с помощью команды.

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

Удаление ресурсов в клиенте B

  1. Войдите в подписку Tenant B с помощью az login команды.

    az login --tenant $TENANT_B_ID

  2. Убедитесь, что вы работаете с правильной подпиской в клиенте B с помощью az account set команды.

    az account set --subscription $TENANT_B_SUBSCRIPTION_ID

  3. Удалите группу ресурсов Azure и все ресурсы в ней az group delete с помощью команды.

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

Следующие шаги

Из этой статьи вы узнали, как настроить удостоверение рабочей нагрузки между клиентами на Служба Azure Kubernetes (AKS). Дополнительные сведения об удостоверениях рабочей нагрузки см. в следующих статьях: