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

Статья
08/02/2024

В этой статье рассматривается миграция из управляемого 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.

Используйте команду 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)"

Предоставьте управляемому удостоверению необходимые разрешения для доступа к ресурсам в Azure. Сведения о том, как это сделать, см. в разделе "Назначение доступа к управляемому удостоверению" к ресурсу.
Чтобы получить 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

Примечание.

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

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

Примечание.

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

Если приложение использует управляемое удостоверение и по-прежнему использует 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 из кластера, а затем удалить удостоверение.

Выполните команду 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 см. в следующей статье "Обзор".

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