Миграция с управляемого удостоверения pod на удостоверение рабочей нагрузки

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

Если вы не знакомы с Идентификация рабочей нагрузки Microsoft Entra, ознакомьтесь со следующей статьей обзора.

Подготовка к работе

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

Сценарии миграции

В этом разделе описаны варианты миграции, доступные в зависимости от того, какая версия пакета SDK для удостоверений Azure установлена.

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

• Создайте учетные данные управляемого удостоверения .
• Свяжите управляемое удостоверение с учетной записью службы Kubernetes, уже используемой для управляемого pod удостоверения или создайте новую учетную запись службы Kubernetes, а затем свяжите ее с управляемым удостоверением.
• Установите федеративное отношение доверия между управляемым удостоверением и идентификатором Microsoft Entra.

Миграция с последней версии

Если приложение уже использует последнюю версию пакета SDK для удостоверений Azure, выполните следующие действия, чтобы завершить настройку проверки подлинности:

• Параллельное развертывание удостоверения рабочей нагрузки с управляемым модулем pod. Вы можете перезапустить развертывание приложения, чтобы начать использовать удостоверение рабочей нагрузки, где оно автоматически внедряет заметки OIDC в приложение.
• После успешной проверки подлинности приложения можно удалить заметки с управляемыми pod удостоверениями из приложения, а затем удалить надстройку управляемого pod удостоверения.

Миграция из более старой версии

Если приложение не использует последнюю версию пакета SDK для удостоверений Azure, у вас есть два варианта:

• Вы можете использовать боковик миграции, который мы предоставляем в приложениях Linux, который прокси-серверы IMDS транзакций приложения выполняет переход к OpenID Connect (OIDC). Боковой автомобиль миграции не предназначен для долгосрочного решения, но способ быстрого выполнения и быстрого выполнения на удостоверениях рабочей нагрузки. Выполните следующие действия.

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

  Примечание.

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

• Переопределите приложение для поддержки последней версии клиентской библиотеки удостоверений Azure. Затем выполните следующие действия:

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

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

Если у вас нет управляемого удостоверения, созданного и назначенного модулем pod, выполните следующие действия, чтобы создать и предоставить необходимые разрешения для хранения, Key Vault или любых ресурсов, необходимых приложению для проверки подлинности в Azure.

1. Используйте команду Azure CLI az account set , чтобы задать определенную подписку для текущей активной подписки. Затем используйте команду az identity create для создания управляемого удостоверения.

   az account set --subscription "subscriptionID"
   

   az identity create --name "userAssignedIdentityName" --resource-group "resourceGroupName" --location "location" --subscription "subscriptionID"
   

   export USER_ASSIGNED_CLIENT_ID="$(az identity show --resource-group "resourceGroupName" --name "userAssignedIdentityName" --query 'clientId' -otsv)"
   

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

3. Чтобы получить URL-адрес издателя OIDC и сохранить его в переменной среды, выполните следующую команду. Замените значения по умолчанию для имени кластера и имени группы ресурсов.

   export AKS_OIDC_ISSUER="$(az aks show --name myAKSCluster --resource-group myResourceGroup --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.

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

Если у вас нет выделенной учетной записи службы Kubernetes, созданной для этого приложения, выполните следующие действия, чтобы создать, а затем идентифицировать его с идентификатором клиента управляемого удостоверения, созданного на предыдущем шаге. Используйте команду az aks get-credentials и замените значения для имени кластера и имени группы ресурсов.

az aks get-credentials --name myAKSCluster --resource-group "${RESOURCE_GROUP}"

Скопируйте и вставьте следующие многострочный ввод в Azure CLI.

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, чтобы создать федеративные учетные данные удостоверения между управляемым удостоверением, издателем учетной записи службы и субъектом. Замените значенияresourceGroupName, , userAssignedIdentityName, serviceAccountNamespacefederatedIdentityNameи serviceAccountName.

az identity federated-credential create --name federatedIdentityName --identity-name userAssignedIdentityName --resource-group resourceGroupName --issuer ${AKS_OIDC_ISSUER} --subject system:serviceaccount:${SERVICE_ACCOUNT_NAMESPACE}:${SERVICE_ACCOUNT_NAME} --audience api://AzureADTokenExchange

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

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

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

• azure.workload.identity/inject-proxy-sidecar— значение или truefalse
• azure.workload.identity/proxy-sidecar-port — значением является нужный порт для прокси-сервера. Значение по умолчанию — 8000.

При создании модуля pod с приведенными выше заметками удостоверение рабочей нагрузки Azure автоматически внедряет контейнер и прокси-контейнер и прокси-контейнер в спецификацию pod.

Веб-перехватчик, который уже запущен, добавляет в развертывание 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. После обновления или развертывания приложения можно проверить, что модуль pod находится в состоянии выполнения с помощью команды kubectl описать pod . Замените значение podName именем образа развернутого модуля pod.

kubectl describe pods podName

Чтобы убедиться, что pod передает транзакции IMDS, используйте команду kubectl logs . Замените значение podName именем образа развернутого модуля pod:

kubectl logs podName

Следующие выходные данные журнала похожи на успешный обмен данными через прокси-сервер. Убедитесь, что в журналах показано, что маркер успешно получен, а операция 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 Microsoft Entra для модуля pod из кластера, а затем удалить удостоверение.

1. Выполните команду az aks pod-identity delete, чтобы удалить удостоверение из pod. Это необходимо сделать только после того, как все модули pod в пространстве имен с помощью сопоставления удостоверений, управляемых pod, перенесены для использования бокового автомобиля.

   az aks pod-identity delete --name podIdentityName --namespace podIdentityNamespace --resource-group myResourceGroup --cluster-name myAKSCluster
   

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

В этой статье показано, как настроить модуль pod для проверки подлинности с помощью удостоверения рабочей нагрузки в качестве варианта миграции. Дополнительные сведения о Идентификация рабочей нагрузки Microsoft Entra см. в следующей статье "Обзор".