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

Статья
02/22/2024

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

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

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

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

Примечание.

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

Экспорт переменных среды

Чтобы упростить действия по настройке удостоверений, описанные ниже, определяют переменные среды для ссылки на кластер.

Выполните следующие команды, чтобы создать эти переменные. Замените значения по умолчанию для RESOURCE_GROUP, , LOCATION, SERVICE_ACCOUNT_NAME, SUBSCRIPTIONUSER_ASSIGNED_IDENTITY_NAMEи FEDERATED_IDENTITY_CREDENTIAL_NAME.

export RESOURCE_GROUP="myResourceGroup"
export LOCATION="westcentralus"
export SERVICE_ACCOUNT_NAMESPACE="default"
export SERVICE_ACCOUNT_NAME="workload-identity-sa"
export SUBSCRIPTION="$(az account show --query id --output tsv)"
export USER_ASSIGNED_IDENTITY_NAME="myIdentity"
export FEDERATED_IDENTITY_CREDENTIAL_NAME="myFedIdentity"

Создание кластера AKS

Создайте кластер AKS с помощью команды az aks create с параметром --enable-oidc-issuer для использования издателя OIDC. В следующем примере создается кластер с именем myAKSCluster с одним узлом в myResourceGroup:

az aks create -g "${RESOURCE_GROUP}" -n myAKSCluster --enable-oidc-issuer --enable-workload-identity --generate-ssh-keys

Через несколько минут выполнение команды завершается и отображаются сведения о кластере в формате JSON.

Примечание.

При создании кластера AKS автоматически создается вторая группа ресурсов для хранения ресурсов AKS. Дополнительные сведения см. в статье "Почему создаются две группы ресурсов с помощью AKS?".

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

Кластер AKS можно обновить с помощью команды az aks update с --enable-oidc-issuer--enable-workload-identity параметром, чтобы использовать издателя OIDC и включить удостоверение рабочей нагрузки. В следующем примере обновляется кластер с именем myAKSCluster:

az aks update -g "${RESOURCE_GROUP}" -n myAKSCluster --enable-oidc-issuer --enable-workload-identity

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

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

export AKS_OIDC_ISSUER="$(az aks show -n myAKSCluster -g "${RESOURCE_GROUP}" --query "oidcIssuerProfile.issuerUrl" -o 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.

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

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

az identity create --name "${USER_ASSIGNED_IDENTITY_NAME}" --resource-group "${RESOURCE_GROUP}" --location "${LOCATION}" --subscription "${SUBSCRIPTION}"

Затем создадим переменную для идентификатора управляемого удостоверения.

export USER_ASSIGNED_CLIENT_ID="$(az identity show --resource-group "${RESOURCE_GROUP}" --name "${USER_ASSIGNED_IDENTITY_NAME}" --query 'clientId' -o tsv)"

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

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

az aks get-credentials -n myAKSCluster -g "${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, чтобы создать федеративные учетные данные удостоверения между управляемым удостоверением, издателем учетной записи службы и субъектом.

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

Примечание.

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

Развертывание приложения

При развертывании модулей pod приложения манифест должен ссылаться на учетную запись службы, созданную на шаге создания учетной записи службы Kubernetes. В следующем манифесте показано, как ссылаться на учетную запись, в частности метаданные\пространство имен и свойства spec\serviceAccountName :

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: your-pod
  namespace: "${SERVICE_ACCOUNT_NAMESPACE}"
  labels:
    azure.workload.identity/use: "true"  # Required, only the pods with this label can use workload identity
spec:
  serviceAccountName: "${SERVICE_ACCOUNT_NAME}"
  containers:
    - image: <your image>
      name: <containerName>
EOF

Внимание

Убедитесь, что модули pod приложения, использующие удостоверение рабочей нагрузки, добавили следующую метку azure.workload.identity/use: "true" в спецификацию pod, в противном случае модули pod завершаются сбоем после их перезапуска.

Необязательно. Предоставление разрешений для доступа к Azure Key Vault

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

Прежде чем продолжить, вам потребуется следующая информация:

Имя Key Vault
Группа ресурсов с хранилищем ключей

Эти сведения можно получить с помощью команды Azure CLI: az keyvault list.

Задайте политику доступа для управляемого удостоверения для доступа к секретам в Key Vault, выполнив следующие команды:

export KEYVAULT_RESOURCE_GROUP="myResourceGroup"
export KEYVAULT_NAME="myKeyVault"
export USER_ASSIGNED_CLIENT_ID="$(az identity show --resource-group "${RESOURCE_GROUP}" --name "${USER_ASSIGNED_IDENTITY_NAME}" --query 'clientId' -o tsv)"

az keyvault set-policy --name "${KEYVAULT_NAME}" --secret-permissions get --spn "${USER_ASSIGNED_CLIENT_ID}"

Создайте секрет в Key Vault:

export KEYVAULT_SECRET_NAME="my-secret"

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

Экспорт URL-адреса Key Vault:

export KEYVAULT_URL="$(az keyvault show -g ${KEYVAULT_RESOURCE_GROUP} -n ${KEYVAULT_NAME} --query properties.vaultUri -o tsv)"

Разверните модуль pod, ссылающийся на учетную запись службы и URL-адрес Key Vault выше:

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: quick-start
  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

Чтобы проверка правильно ли внедряются все свойства веб-перехватчиком, используйте команду kubectl описать:

kubectl describe pod quick-start | grep "SECRET_NAME:"

При успешном выполнении выходные данные должны быть похожи на следующие:

      SECRET_NAME:                 ${KEYVAULT_SECRET_NAME}

Чтобы убедиться, что модуль pod может получить маркер и получить доступ к ресурсу, используйте команду kubectl logs:

kubectl logs quick-start

При успешном выполнении выходные данные должны быть похожи на следующие:

I0114 10:35:09.795900       1 main.go:63] "successfully got secret" secret="Hello\\!"

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

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

az aks update --resource-group "${RESOURCE_GROUP}" --name myAKSCluster --disable-workload-identity

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

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

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

Экспорт переменных среды

Создание кластера AKS

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

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

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

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

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

Развертывание приложения

Необязательно. Предоставление разрешений для доступа к Azure Key Vault

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

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

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