Развертывание и настройка идентификатора рабочей нагрузки Microsoft Entra в кластере Службы Azure Kubernetes (AKS)

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

Создайте новый или обновите существующий кластер AKS с помощью Azure CLI с издателем OpenID Connect (OIDC) и включенным идентификатором рабочей нагрузки Microsoft Entra.
Создайте идентификацию рабочей нагрузки и учетную запись службы Kubernetes.
Настройте управляемое удостоверение для федерации маркеров.
Разверните рабочую нагрузку и проверьте проверку подлинности с помощью удостоверения рабочей нагрузки.
При необходимости предоставьте pod в кластере доступ к секретам в хранилище ключей Azure.

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

Если у вас нет аккаунта Azure, создайте бесплатную учетную запись перед началом.
Для этой статьи требуется версия 2.47.0 или более поздняя версия Azure CLI. Если вы используете Azure Cloud Shell, последняя версия уже установлена.
Убедитесь, что удостоверение, которое вы используете для создания кластера, имеет соответствующие минимальные разрешения. Дополнительные сведения см. в разделе "Параметры доступа и удостоверения" для службы Azure Kubernetes (AKS).
Если у вас несколько подписок Azure, выберите соответствующий идентификатор подписки, в котором должны выставляться счета за ресурсы с помощью az account set команды.

Примечание.

Соединитель служб можно использовать для автоматической настройки некоторых шагов. Дополнительные сведения см. в руководстве: подключение к учетной записи хранения Azure в Azure Kubernetes Service (AKS) с помощью Service Connector и Workload ID Microsoft Entra.

Создание или изменение группы ресурсов

Создайте группу ресурсов с помощью команды az group create.

export RANDOM_ID="$(openssl rand -hex 3)"
export RESOURCE_GROUP="myResourceGroup$RANDOM_ID"
export LOCATION="<your-preferred-region>"
az group create --name "${RESOURCE_GROUP}" --location "${LOCATION}"

Включение издателя OIDC и идентификатора рабочей нагрузки Microsoft Entra в кластере AKS

Вы можете включить издателя OIDC и идентификатор рабочей нагрузки Microsoft Entra в новом или существующем кластере AKS.

Создание нового кластера AKS
Обновление существующего кластера AKS

Создайте кластер AKS, используя команду az aks create с параметром --enable-oidc-issuer, чтобы включить OIDC issuer, и параметр --enable-workload-identity, чтобы активировать Microsoft Entra Workload ID. В следующем примере создается кластер с одним узлом:
```
export CLUSTER_NAME="myAKSCluster$RANDOM_ID"
az aks create \
    --resource-group "${RESOURCE_GROUP}" \
    --name "${CLUSTER_NAME}" \
    --enable-oidc-issuer \
    --enable-workload-identity \
    --generate-ssh-keys
```
Через несколько минут выполнение команды завершается и отображаются сведения о кластере в формате JSON.

Обновите существующий кластер AKS, чтобы включить издателя OIDC и идентификатор рабочей нагрузки Entra, с помощью команды az aks update с параметрами --enable-oidc-issuer и --enable-workload-identity.
```
az aks update \
    --resource-group "${RESOURCE_GROUP}" \
    --name "${CLUSTER_NAME}" \
    --enable-oidc-issuer \
    --enable-workload-identity
```

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

Получите URL-адрес издателя OIDC и сохраните его в переменной среды с помощью команды [az aks show][az-aks-show].
```
export AKS_OIDC_ISSUER="$(az aks show --name "${CLUSTER_NAME}" \
    --resource-group "${RESOURCE_GROUP}" \
    --query "oidcIssuerProfile.issuerUrl" \
    --output tsv)"
```
Переменная среды должна содержать URL-адрес издателя, аналогичный следующему примеру:
```
https://eastus.oic.prod-aks.azure.com/00000000-0000-0000-0000-000000000000/11111111-1111-1111-1111-111111111111/
```
По умолчанию издателю присваивается базовый URL-адрес https://{region}.oic.prod-aks.azure.com/{tenant_id}/{uuid}, где значение для {region} соответствия расположению, в котором развертывается кластер AKS. Значение {uuid} представляет ключ OIDC, который является случайным образом созданным и неизменяемым GUID для каждого кластера.

Создание управляемого удостоверения

Получите идентификатор подписки и сохраните его в переменную среды с помощью команды [][az account showaz-account-show].
```
export SUBSCRIPTION="$(az account show --query id --output tsv)"
```

Создайте пользовательское управляемое удостоверение с помощью команды az identity create.

export USER_ASSIGNED_IDENTITY_NAME="myIdentity$RANDOM_ID"
az identity create \
    --name "${USER_ASSIGNED_IDENTITY_NAME}" \
    --resource-group "${RESOURCE_GROUP}" \
    --location "${LOCATION}" \
    --subscription "${SUBSCRIPTION}"

В следующем примере выходных данных показано успешное создание управляемого удостоверения:

{
  "clientId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "id": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourcegroups/myResourceGroupxxxxxx/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myIdentityxxxxxx",
  "location": "eastus",
  "name": "myIdentityxxxxxx",
  "principalId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "resourceGroup": "myResourceGroupxxxxxx",
  "systemData": null,
  "tags": {},
  "tenantId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "type": "Microsoft.ManagedIdentity/userAssignedIdentities"
}

Получите идентификатор управляемой идентичности и сохраните его в переменной среды, используя команду [az identity show][az-identity-show].
```
export USER_ASSIGNED_CLIENT_ID="$(az identity show \
    --resource-group "${RESOURCE_GROUP}" \
    --name "${USER_ASSIGNED_IDENTITY_NAME}" \
    --query 'clientId' \
    --output tsv)"
```

Создание учетной записи службы Kubernetes

Подключитесь к вашему кластеру AKS, используя команду az aks get-credentials.
```
az aks get-credentials --name "${CLUSTER_NAME}" --resource-group "${RESOURCE_GROUP}"
```
Создайте учетную запись службы Kubernetes и аннотируйте ее идентификатором клиента управляемой учетной записи, применяя следующий манифест с помощью команды kubectl apply.
```
export SERVICE_ACCOUNT_NAME="workload-identity-sa$RANDOM_ID"
export SERVICE_ACCOUNT_NAMESPACE="default"
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    azure.workload.identity/client-id: "${USER_ASSIGNED_CLIENT_ID}"
  name: "${SERVICE_ACCOUNT_NAME}"
  namespace: "${SERVICE_ACCOUNT_NAMESPACE}"
EOF
```
В следующих выходных данных показано успешное создание удостоверения рабочей нагрузки:
```
serviceaccount/workload-identity-sa created
```

Создание учетных данных федеративного удостоверения

Создайте учетные данные для федеративной идентификации между управляемым удостоверением, издателем учетной записи службы и субъектом с помощью команды az identity federated-credential create.
```
export FEDERATED_IDENTITY_CREDENTIAL_NAME="myFedIdentity$RANDOM_ID"
az identity federated-credential create \
    --name ${FEDERATED_IDENTITY_CREDENTIAL_NAME} \
    --identity-name "${USER_ASSIGNED_IDENTITY_NAME}" \
    --resource-group "${RESOURCE_GROUP}" \
    --issuer "${AKS_OIDC_ISSUER}" \
    --subject system:serviceaccount:"${SERVICE_ACCOUNT_NAMESPACE}":"${SERVICE_ACCOUNT_NAME}" \
    --audience api://AzureADTokenExchange
```
Примечание.

После добавления учетные данные федеративного удостоверения требуется несколько секунд для их распространения. Если запрос маркера выполняется сразу после добавления учетных данных федеративного удостоверения, запрос может завершиться ошибкой до обновления кэша. Чтобы избежать этой проблемы, можно добавить небольшую задержку после добавления учетных данных федеративного удостоверения.

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

Создание хранилища ключей с авторизацией Azure RBAC

В следующем примере показано, как использовать модель управления доступом на основе ролей Azure (Azure RBAC) для предоставления pod-доступа к хранилищу ключей. Дополнительные сведения о модели разрешений Azure RBAC для Azure Key Vault см. в статье Предоставление разрешений приложениям для доступа к хранилищу ключей Azure с помощью Azure RBAC.

Создайте хранилище ключей с защитой от очистки, включив авторизацию Azure RBAC, с помощью команды [az keyvault create][az-keyvault-create]. Вы также можете использовать существующее хранилище ключей, если оно настроено для защиты от очистки и авторизации Azure RBAC:
```
export KEYVAULT_NAME="keyvault-workload-id$RANDOM_ID" # Ensure the key vault name is between 3-24 characters
az keyvault create \
    --name "${KEYVAULT_NAME}" \
    --resource-group "${RESOURCE_GROUP}" \
    --location "${LOCATION}" \
    --enable-purge-protection \
    --enable-rbac-authorization
```
Получите идентификатор ресурса хранилища ключей и сохраните его в переменную среды с помощью команды [az keyvault show][az-keyvault-show].
```
export KEYVAULT_RESOURCE_ID=$(az keyvault show --resource-group "${RESOURCE_GROUP}" \
    --name "${KEYVAULT_NAME}" \
    --query id \
    --output tsv)
```

Назначение прав доступа RBAC для управления хранилищем ключей

Получите идентификатор вызывающего объекта и сохраните его в переменную среды с помощью команды [az ad signed-in-user show][az ad signed-in-user show].
```
export CALLER_OBJECT_ID=$(az ad signed-in-user show --query id -o tsv)
```
Назначьте себе роль офицера секретов Хранилища ключей Azure RBAC, чтобы создать секрет в новом хранилище ключей с помощью команды [az role assignment create][az-role-assignment-create].
```
az role assignment create --assignee "${CALLER_OBJECT_ID}" \
    --role "Key Vault Secrets Officer" \
    --scope "${KEYVAULT_RESOURCE_ID}"
```

Создание и настройка секретного доступа

Создайте секрет в хранилище ключей с помощью команды [az keyvault secret set][az-keyvault-secret-set].

export KEYVAULT_SECRET_NAME="my-secret$RANDOM_ID"
az keyvault secret set \
    --vault-name "${KEYVAULT_NAME}" \
    --name "${KEYVAULT_SECRET_NAME}" \
    --value "Hello\!"

Получите основной идентификатор управляемой идентичности, назначенной пользователем, и сохраните его в переменной окружения с помощью команды [az identity show][az-identity-show].
```
export IDENTITY_PRINCIPAL_ID=$(az identity show \
    --name "${USER_ASSIGNED_IDENTITY_NAME}" \
    --resource-group "${RESOURCE_GROUP}" \
    --query principalId \
    --output tsv)
```
Назначьте роль пользователя секретов Key Vault пользовательскому управляемому удостоверению с помощью команды [az role assignment create][az-role-assignment-create]. Этот шаг предоставляет управляемому удостоверению разрешение на чтение секретов из хранилища ключей.
```
az role assignment create \
    --assignee-object-id "${IDENTITY_PRINCIPAL_ID}" \
    --role "Key Vault Secrets User" \
    --scope "${KEYVAULT_RESOURCE_ID}" \
    --assignee-principal-type ServicePrincipal
```
Создайте переменную среды для URL-адреса хранилища ключей с помощью команды [][az keyvault showaz-keyvault-show]:
```
export KEYVAULT_URL="$(az keyvault show \
    --resource-group "${RESOURCE_GROUP}" \
    --name ${KEYVAULT_NAME} \
    --query properties.vaultUri \
    --output tsv)"
```

Разверните pod для проверки и тестирования доступа

Разверните pod, чтобы подтвердить, что идентификатор рабочей нагрузки может получить доступ к секрету в хранилище ключей. В следующем примере используется образ ghcr.io/azure/azure-workload-identity/msal-go, содержащий пример приложения, использующего Microsoft Entra Workload ID для извлечения секрета из Azure Key Vault.

kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
    name: sample-workload-identity-key-vault
    namespace: ${SERVICE_ACCOUNT_NAMESPACE}
    labels:
        azure.workload.identity/use: "true"
spec:
    serviceAccountName: ${SERVICE_ACCOUNT_NAME}
    containers:
      - image: ghcr.io/azure/azure-workload-identity/msal-go
        name: oidc
        env:
          - name: KEYVAULT_URL
            value: ${KEYVAULT_URL}
          - name: SECRET_NAME
            value: ${KEYVAULT_SECRET_NAME}
    nodeSelector:
        kubernetes.io/os: linux
EOF

Подождите, пока pod будет в состоянии Ready с помощью команды kubectl wait.

kubectl wait --namespace ${SERVICE_ACCOUNT_NAMESPACE} --for=condition=Ready pod/sample-workload-identity-key-vault --timeout=120s

Убедитесь, что переменная среды SECRET_NAME задана в поде с помощью команды kubectl describe.
```
kubectl describe pod sample-workload-identity-key-vault | grep "SECRET_NAME:"
```
В случае успешного выполнения выходные данные должны быть похожи на следующий пример:
```
SECRET_NAME: ${KEYVAULT_SECRET_NAME}
```
Убедитесь, что pod-ы могут получить токен и доступ к ресурсу с помощью команды kubectl logs.
```
kubectl logs sample-workload-identity-key-vault
```
В случае успешного выполнения выходные данные должны быть похожи на следующий пример:
```
I0114 10:35:09.795900       1 main.go:63] "successfully got secret" secret="Hello\\!"
```
Внимание

Назначения ролей RBAC Azure могут распространяться в течение до 10 минут. Если модуль pod не может получить доступ к секрету, может потребоваться ждать распространения назначения роли. Дополнительные сведения см. в статье об устранении неполадок службы Azure RBAC.

Отключение идентификатора рабочей нагрузки Microsoft Entra в кластере AKS

Отключите Идентификатор Рабочей Нагрузки Microsoft Entra в кластере AKS, в котором он был активирован и настроен, а затем обновите кластер AKS с помощью команды az aks update и параметра --disable-workload-identity.
```
az aks update \
    --resource-group "${RESOURCE_GROUP}" \
    --name "${CLUSTER_NAME}" \
    --disable-workload-identity
```

В этой статье вы развернули кластер Kubernetes и настроили его для использования Workload ID Microsoft Entra, чтобы рабочие нагрузки приложений могли аутентифицироваться этими учетными данными. Теперь вы готовы развернуть приложение и настроить его для использования удостоверения рабочей нагрузки с последней версией клиентской библиотеки удостоверений Azure. Если вы не можете перезаписать приложение для использования последней версии клиентской библиотеки, вы можете настроить модуль pod приложения для проверки подлинности с помощью управляемого удостоверения с удостоверением рабочей нагрузки в качестве краткосрочного решения миграции.

Интеграция соединителя служб помогает упростить конфигурацию подключения для рабочих нагрузок AKS и служб резервного копирования Azure. Он безопасно обрабатывает проверку подлинности и конфигурации сети и следует рекомендациям по подключению к службам Azure. Дополнительные сведения см. в статье "Подключение к Azure OpenAI" в модели Foundry в AKS с помощью удостоверения рабочей нагрузки Microsoft Entra и соединителя служб.

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2025-12-10