Развертывание и настройка удостоверения рабочей нагрузки в кластере Служба Azure Kubernetes (AKS)
Служба 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
, SUBSCRIPTION
USER_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 приложения для проверки подлинности с помощью управляемого удостоверения с удостоверением рабочей нагрузки в качестве краткосрочного решения миграции.