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

Переход pod AKS от pod-управляемых удостоверений к идентификатору рабочей нагрузки Microsoft Entra (удостоверение рабочей нагрузки) с использованием одного из трех подходов в зависимости от текущей версии Azure Identity SDK: параллельное развертывание с последней версией SDK, прокси-сервер sidecar для миграции (только для Linux) или переписывание SDK.

Предпосылки

Azure CLI версии 2.47.0 или более поздней. az --version Выполните команду, чтобы найти версию. Если вам нужно установить или обновить, см. статью "Установка Azure CLI".

Настройка переменных среды

В следующей таблице перечислены переменные среды, используемые в командах в этой статье. Обязательно замените значения заполнителя собственными значениями.

Переменная среды	Description	Пример значения
`SUBSCRIPTION_ID`	Идентификатор подписки Azure, в которой создается кластер AKS и управляемое удостоверение.	`00000000-0000-0000-0000-000000000000`
`RESOURCE_GROUP`	Имя группы ресурсов, в которой создается кластер AKS и управляемое удостоверение.	`myResourceGroup`
`LOCATION`	Регион Azure, в котором создается кластер AKS и управляемое удостоверение.	`eastus`
`CLUSTER_NAME`	Имя кластера AKS.	`myAKSCluster`
`MANAGED_IDENTITY_NAME`	Имя назначаемого пользователем управляемого удостоверения.	`myManagedIdentity`
`SERVICE_ACCOUNT_NAME`	Имя учетной записи службы Kubernetes для создания или связывания с управляемым удостоверением.	`workload-identity-sa`
`SERVICE_ACCOUNT_NAMESPACE`	Пространство имен учетной записи службы Kubernetes.	`default`
`FEDERATED_IDENTITY_NAME`	Имя создаваемого федеративного удостоверения личности.	`myFederatedIdentity`

Выбор пути миграции

Выберите подходящий подход к миграции на основе текущей версии пакета SDK для удостоверений Azure:

Последняя версия пакета SDK для удостоверений Azure: Если ваше приложение уже использует последнюю версию пакета SDK для удостоверений Azure, можно мигрировать, развернув идентификатор рабочей нагрузки Microsoft Entra параллельно с существующим управляемым идентификатором pod.
Старый пакет SDK с миграционным сайдкаром - Если ваше приложение использует более раннюю версию SDK и работает в контейнерах Linux, вы можете использовать временный миграционный сайдкар для проксирования транзакций службы метаданных экземпляра (IMDS) при планировании обновления вашего SDK.
Старый подход к перезаписи пакета SDK. Если приложение использует более старую версию пакета SDK, можно обновить код приложения, чтобы использовать последний пакет SDK для удостоверений Azure, а затем перейти на удостоверение рабочей нагрузки.

Подготовка к миграции

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

Создать учетные данные управляемой идентичности
Свяжите управляемое удостоверение, назначаемое пользователем, с учетной записью службы Kubernetes, которая уже используется для управляемого удостоверения pod, или создайте новую учетную запись службы Kubernetes , а затем свяжите ее с управляемым удостоверением.
Установите федеративное отношение доверия между управляемым удостоверением и идентификатором Microsoft Entra с помощью URL-адреса издателя OpenID Connect (OIDC) и учетной записи службы.

Миграция с последней версии пакета SDK для удостоверений Azure

Этот путь миграции применяется, когда приложение уже использует последнюю версию пакета SDK для удостоверений Azure, и вы хотите выполнить миграцию с минимальными изменениями кода.

Подход к миграции: Развертывание идентификатора рабочей нагрузки Microsoft Entra параллельно с управляемой pod личностью, проверка функциональности, затем удаление управляемой pod личности.

Пошаговые инструкции

Развертывание идентификатора рабочей нагрузки Microsoft Entra параллельно с существующим удостоверением, управляемым pod.
Перезапустите развертывание приложения, чтобы начать использование идентификатора рабочей нагрузки Microsoft Entra (заметки OIDC внедряются автоматически).
Убедитесь, что приложение может успешно пройти проверку подлинности с помощью рабочей идентификации.
Удалите заметки, управляемые модулем pod, из приложения.
Удалите надстройку pod-управляемого удостоверения из кластера.

Используйте сайдкар миграции (только для контейнеров Linux)

Этот путь миграции применяется, если приложение использует старую версию пакета SDK для удостоверений Azure, выполняется в контейнерах Linux и требуется временное решение при планировании обновлений пакета SDK.

Подход к миграции: разверните миграционный сайдкар, который проксирует транзакции IMDS в OIDC, что позволяет существующему коду приложения работать без необходимости изменений сразу.

Важные ограничения:

Только контейнеры Linux. Контейнеры Windows не поддерживаются.
Временное решение , которое не предназначено для долгосрочного использования в рабочей среде.
Требуется планирование для расписания обновлений SDK для долгосрочной поддержки.

Пошаговые инструкции

Разверните нагрузку с сайдкаром миграции, чтобы проксировать транзакции IMDS.
Убедитесь, что транзакции проверки подлинности успешно завершены.
Запланируйте обновления SDK для приложений для поддерживаемых версий Azure Identity.
После обновления пакетов SDK, удалите прокси-сайдкар и повторно разверните приложения.

Обновление приложения для использования последней версии SDK Azure Identity

Этот путь миграции применяется, если приложение использует более старую версию пакета SDK для удостоверений Azure и хотите обновить до последней поддерживаемой версии пакета SDK перед миграцией.

Подход к миграции: обновите код приложения, чтобы использовать последний пакет SDK для удостоверений Azure, а затем перейдите в идентификатор рабочей нагрузки Microsoft Entra с обновленным кодом.

Технические результаты:

Использует актуальную версию пакета SDK для удостоверений Azure (без запланированных сроков устаревания).
Поддерживает контейнеры Linux и Windows (в отличие от подхода sidecar).
Устраняет нагрузку на прокси-компоненты и перевод IMDS.

Пошаговые инструкции

Обновите код вашего приложения для использования последней версии Azure Identity SDK.
Протестируйте обновленное приложение с pod-управляемым удостоверением.
Перезапустите развертывание приложения, чтобы начать аутентификацию с использованием Microsoft Entra Workload ID (аннотации OIDC интегрируются автоматически).
Убедитесь, что транзакции проверки подлинности успешно завершены.
Удалите заметки и надстройки, управляемые модулем pod.

Настройка активной подписки Azure

Задайте определенную подписку Azure в качестве текущей активной подписки с помощью az account set команды.
```
az account set --subscription $SUBSCRIPTION_ID
```

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

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

az identity create --name $MANAGED_IDENTITY_NAME --resource-group $RESOURCE_GROUP --location $LOCATION --subscription $SUBSCRIPTION_ID

Получите идентификатор клиента управляемого удостоверения

Получите идентификатор клиента управляемого удостоверения и сохраните его в переменной среды с помощью az identity show команды.
```
export USER_ASSIGNED_CLIENT_ID="$(az identity show --resource-group $RESOURCE_GROUP --name $MANAGED_IDENTITY_NAME --query 'clientId' -otsv)"
```

Предоставление управляемому удостоверению доступа к ресурсам Azure

Предоставьте управляемому удостоверению разрешения, необходимые для доступа к необходимым ресурсам Azure. Выполните инструкции в разделе "Назначение управляемому удостоверению доступа к ресурсу", чтобы назначить соответствующую роль управляемому удостоверению.

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

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

Получение учетных данных кластера AKS

Получите учетные данные кластера AKS с помощью az aks get-credentials команды.
```
az aks get-credentials --name $CLUSTER_NAME --resource-group $RESOURCE_GROUP
```

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

Создайте учетную запись службы Kubernetes и аннотируйте её идентификатором клиента управляемого удостоверения с помощью команды kubectl apply. Обязательно замените значения заполнителя собственными значениями.
```
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 с помощью команды.
```
az identity federated-credential create --name $FEDERATED_IDENTITY_NAME --identity-name $MANAGED_IDENTITY_NAME --resource-group $RESOURCE_GROUP --issuer ${AKS_OIDC_ISSUER} --subject system:serviceaccount:${SERVICE_ACCOUNT_NAMESPACE}:${SERVICE_ACCOUNT_NAME} --audience api://AzureADTokenExchange
```
Учётные данные федеративной идентификации начинают распространяться через несколько минут после добавления. Если запрос токена выполняется сразу после добавления кредитных данных федеративной личности, запрос токена может завершиться ошибкой, так как кэш каталога Azure AD содержит устаревшие сведения.

Развертывание рабочей нагрузки с помощью бокового автомобиля миграции

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

Чтобы обновить или развернуть рабочую нагрузку, добавьте следующие аннотации pod в спецификацию pod (только если вы хотите использовать сайдкар миграции).

Заметка Pod	Description	Ценность
`azure.workload.identity/inject-proxy-sidecar`	Указывает, следует ли внедрить прокси-сайдкар в pod.	`true` или `false`
`azure.workload.identity/proxy-sidecar-port`	Требуемый порт для прокси-сайдкара.	Значение по умолчанию: `8000`

При создании pod с этими аннотациями мутирующий веб-перехватчик Microsoft Entra Workload ID автоматически внедряет init-container и прокси-сайдкар в спецификацию pod. В следующем YAML показан пример того, что мутирующий веб-перехватчик добавляет в развертывание pod:

apiVersion: v1
kind: Pod
metadata:
  name: httpbin-pod
  labels:
    app: httpbin
    azure.workload.identity/use: "true"
  annotations:
    azure.workload.identity/inject-proxy-sidecar: "true"
spec:
  serviceAccountName: workload-identity-sa
  initContainers:
  - name: init-networking
    image: mcr.microsoft.com/oss/azure/workload-identity/proxy-init:v1.1.0
    securityContext:
      capabilities:
        add:
        - NET_ADMIN
        drop:
        - ALL
      privileged: true
      runAsUser: 0
    env:
    - name: PROXY_PORT
      value: "8000"
  containers:
  - name: nginx
    image: nginx:alpine
    ports:
    - containerPort: 80
  - name: proxy
    image: mcr.microsoft.com/oss/azure/workload-identity/proxy:v1.1.0
    ports:
    - containerPort: 8000

Проверка рабочей нагрузки с помощью боковой коляски миграции

Убедитесь, что модуль pod находится в состоянии выполнения с помощью kubectl describe pod команды. Замените <pod-name> именем модуля pod.
```
kubectl describe pods <pod-name>
```

Убедитесь, что модуль pod передает транзакции IMDS с помощью kubectl logs команды. Замените <pod-name> именем модуля pod.

kubectl logs <pod-name>

В следующем примере выходные данные журнала похожи на успешный обмен данными через прокси-сервер. Убедитесь, что журналы показывают, что маркер успешно получен, и операция GET была успешной.

I0926 00:29:29.968723       1 proxy.go:97] proxy "msg"="starting the proxy server" "port"=8080 "userAgent"="azure-workload-identity/proxy/v0.13.0-12-gc8527f3 (linux/amd64) c8527f3/2022-09-26-00:19"
I0926 00:29:29.972496       1 proxy.go:173] proxy "msg"="received readyz request" "method"="GET" "uri"="/readyz"
I0926 00:29:30.936769       1 proxy.go:107] proxy "msg"="received token request" "method"="GET" "uri"="/metadata/identity/oauth2/token?resource=https://management.core.windows.net/api-version=2018-02-01&client_id=<client_id>"
I0926 00:29:31.101998       1 proxy.go:129] proxy "msg"="successfully acquired token" "method"="GET" "uri"="/metadata/identity/oauth2/token?resource=https://management.core.windows.net/api-version=2018-02-01&client_id=<client_id>"

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

После завершения тестирования и успешного получения приложением токена с помощью прокси-сайдкара, вы можете удалить сопоставление удостоверений и удостоверений, управляемых через pod, из кластера AKS.

Удалите привязку идентификации, управляемой pod, из вашего pod с помощью команды az aks pod-identity delete. Замените <pod-identity-name> и <pod-identity-namespace> на имя и пространство имен вашей под-идентификации.
```
az aks pod-identity delete --name <pod-identity-name> --namespace <pod-identity-namespace> --resource-group $RESOURCE_GROUP --cluster-name $CLUSTER_NAME
```

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

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

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

Last updated on 2026-01-06

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

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

Предпосылки

Настройка переменных среды

Выбор пути миграции

Подготовка к миграции

Миграция с последней версии пакета SDK для удостоверений Azure

Используйте сайдкар миграции (только для контейнеров Linux)

Обновление приложения для использования последней версии SDK Azure Identity

Настройка активной подписки Azure

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

Получите идентификатор клиента управляемого удостоверения

Предоставление управляемому удостоверению доступа к ресурсам Azure

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

Получение учетных данных кластера AKS

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

Установление доверия федеративных удостоверений личности

Развертывание рабочей нагрузки с помощью бокового автомобиля миграции

Проверка рабочей нагрузки с помощью боковой коляски миграции

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

Связанный контент

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

Дополнительные ресурсы