Развертывание и настройка удостоверения рабочей нагрузки в AKS, включенного кластером Azure Arc (предварительная версия)

Статья
12/20/2024

Область применения: Локальная версия Azure, версия 23H2

Федерация удостоверений рабочей нагрузки позволяет настроить управляемое удостоверение, назначаемое пользователем, или регистрацию приложения в идентификаторе Microsoft Entra, чтобы доверять маркерам от внешнего поставщика удостоверений (IdP), например Kubernetes, что обеспечивает доступ к ресурсам, защищенным Microsoft Entra, например Azure Key Vault или хранилищем BLOB-объектов Azure.

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

Создайте кластер AKS Arc с включенным удостоверением рабочей нагрузки (предварительная версия).
Создайте учетную запись службы Kubernetes и привязите ее к управляемому удостоверению Azure.
Создайте федеративные учетные данные в управляемом удостоверении, чтобы доверять издателю OIDC.
Разверните приложение.
Пример. Предоставление pod в кластере доступа к секретам в хранилище ключей Azure.

Для концептуального обзора федерации удостоверений рабочей нагрузки см. в Kubernetes с поддержкой Azure Arc (предварительная версия).

Внимание

Эти функции предварительной версии доступны на основе самообслуживания. Предварительные версии предоставляются "как есть" и "при наличии". На них не распространяются соглашения об уровне обслуживания и ограниченная гарантия. Служба Azure Kubernetes, включенные предварительными версиями Azure Arc, частично охватываются поддержкой клиентов на основе наилучших усилий.

Примечание.

В общедоступной предварительной версии AKS на платформе Azure Local версия 23H2 поддерживает включение удостоверения рабочей нагрузки во время создания кластера AKS. Однако включение удостоверения рабочей нагрузки после создания кластера или отключения его после этого не поддерживается.

Необходимые компоненты

Перед развертыванием кластера Kubernetes с поддержкой Azure Arc необходимо иметь следующие предварительные требования:

Если у вас нет подписки Azure, создайте бесплатную учетную запись перед началом работы.
Для этой статьи требуется версия 1.4.23 или более поздняя версия Azure CLI. Если вы используете Azure Cloud Shell, последняя версия уже установлена.

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

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

$AZSubscriptionID = "00000000-0000-0000-0000-000000000000" 
$Location = "westeurope" 
$resource_group_name = "myResourceGroup" 

$aks_cluster_name = "myAKSCluster" 

$SERVICE_ACCOUNT_NAMESPACE = "default" 
$SERVICE_ACCOUNT_NAME = "workload-identity-sa" 

$FedIdCredentialName = "myFedIdentity" 
$MSIName = "myIdentity" 

# To access key vault secrets from a pod in the cluster, include these variables:
$KVName = "KV-workload-id" 
$KVSecretName= "KV-secret"

Задание активной подписки

Сначала задайте подписку в качестве текущей активной подписки. Выполните команду az account set с идентификатором подписки:

az login  
az account set -s $AZSubscriptionID

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

Группа ресурсов Azure — это логическая группа, в которой развертываются и управляются ресурсы Azure. При создании группы ресурсов вам будет предложено указать расположение. Это расположение хранилища метаданных группы ресурсов и место, где ресурсы выполняются в Azure, если вы не указываете другой регион во время создания ресурса.

Чтобы создать группу ресурсов, выполните команду az group create.

az group create --name $resource_group_name --location $Location

В следующем примере выходных данных показано успешное создание группы ресурсов:

{ 
  "id": "/subscriptions/<guid>/resourceGroups/myResourceGroup", 
  "location": "westeurope", 
  "managedBy": null, 
  "name": "$resource_group_name", 
  "properties": { 
    "provisioningState": "Succeeded" 
  }, 
  "tags": null 
}

Шаг 1. Создание кластера AKS Arc с включенным удостоверением рабочей нагрузки

Чтобы создать кластер AKS Arc, вам потребуется как значение, так $customlocation_ID и $logicnet_Id значение.

$customlocation_ID: идентификатор Azure Resource Manager пользовательского расположения. Настраиваемое расположение конфигурируется при развертывании локального кластера Azure, версии 23H2. Администратор инфраструктуры должен предоставить идентификатор Resource Manager пользовательского расположения. Вы также можете получить идентификатор Resource Manager, $customlocation_ID = $(az customlocation show --name "<your-custom-location-name>" --resource-group $resource_group_name --query "id" -o tsv)если администратор инфраструктуры предоставляет имя пользовательского расположения и имя группы ресурсов.
$logicnet_Id: идентификатор Azure Resource Manager локальной логической сети Azure, созданной на следующих шагах. Администратор инфраструктуры должен предоставить идентификатор Resource Manager логической сети. Вы также можете получить идентификатор Resource Manager, $logicnet_Id = $(az stack-hci-vm network lnet show --name "<your-lnet-name>" --resource-group $resource_group_name --query "id" -o tsv)если администратор инфраструктуры предоставляет имя логической сети и имя группы ресурсов.

Выполните команду az aksarc create с параметром--enable-oidc-issuer --enable-workload-identity. Укажите идентификаторы entra-admin-group-object-ids и убедитесь, что вы являетесь членом группы администрирования идентификатора Microsoft Entra ID для доступа в режиме прокси-сервера:

az aksarc create  
-n $aks_cluster_name -g $resource_group_name  
--custom-location $customlocation_ID --vnet-ids $logicnet_Id  
--aad-admin-group-object-ids <entra-admin-group-object-ids> 
--generate-ssh-keys  
--enable-oidc-issuer --enable-workload-identity

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

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

az connectedk8s show -n $aks_cluster_name -g $resource_group_name

# agentState = "Succeeded" 
"agentPublicKeyCertificate": "", 
  "agentVersion": "1.21.10", 
  "arcAgentProfile": { 
    "agentAutoUpgrade": "Enabled", 
    "agentErrors": [], 
    "agentState": "Succeeded", 
    "desiredAgentVersion": "", 
    "systemComponents": null 

# oidcIssuerProfile "enabled": true and "issuerUrl" present 

"oidcIssuerProfile": { 
    "enabled": true, 
    "issuerUrl": "https://oidcdiscovery-{location}-endpoint-1111111111111111.000.azurefd.net/00000000-0000-0000-0000-000000000000/11111111-1111-1111-1111-111111111111/"}

В портал Azure можно просмотреть расширение wiextension в разделе "Свойства" кластера Kubernetes.

Внимание

В рамках улучшения безопасности кластеров AKS Arc включение удостоверений рабочей нагрузки активирует два изменения. Во-первых, ключ подписывания учетной записи службы Kubernetes автоматически поворачивается каждые 45 дней и остается действительным в течение 90 дней. Во-вторых, --service-account-extend-token-expiration флаг отключен, уменьшая срок действия маркера с одного года до максимума 24 часов.

Сохранение URL-адреса издателя OIDC в переменной среды

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

$SERVICE_ACCOUNT_ISSUER =$(az connectedk8s show --n $aks_cluster_name --resource-group $resource_group_name --query "oidcIssuerProfile.issuerUrl" --output tsv)

Шаг 2. Создание учетной записи службы Kubernetes и привязка ее к управляемому удостоверению Azure

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

az identity create --name $MSIName --resource-group $resource_group_name --location $Location --subscription $AZSubscriptionID

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

$MSIId=$(az identity show --resource-group $resource_group_name --name $MSIName --query 'clientId' --output tsv)
$MSIPrincipalId=$(az identity show --resource-group $resource_group_name --name $MSIName --query 'principalId' --output tsv)

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

Создайте учетную запись службы Kubernetes и заметите ее с идентификатором клиента управляемого удостоверения, созданного на предыдущем шаге:

az connectedk8s proxy -n $aks_cluster_name -g $resource_group_name

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

$yaml = @" apiVersion: v1 kind: ServiceAccount metadata: annotations: azure.workload.identity/client-id: $MSIId name: $SERVICE_ACCOUNT_NAME namespace: $SERVICE_ACCOUNT_NAMESPACE "@ $yaml = $yaml -replace '\$MSIId', $MSIId ` -replace '\$SERVICE_ACCOUNT_NAME', $SERVICE_ACCOUNT_NAME ` -replace '\$SERVICE_ACCOUNT_NAMESPACE', $SERVICE_ACCOUNT_NAMESPACE $yaml | kubectl apply -f -

В следующих выходных данных показано успешное создание учетной записи службы:

serviceaccount/workload-identity-sa created

Шаг 3. Создание федеративных учетных данных в управляемом удостоверении для доверия издателю OIDC

Сначала создайте учетные данные федеративного удостоверения. Вызовите команду az identity federated-credential create, чтобы создать федеративные учетные данные удостоверения между управляемым удостоверением, издателем учетной записи службы и субъектом. Дополнительные сведения об учетных данных федеративных удостоверений в Microsoft Entra см. в разделе "Обзор федеративных учетных данных удостоверений" в идентификаторе Microsoft Entra.

# Create a federated credential 

az identity federated-credential create --name $FedIdCredentialName --identity-name $MSIName --resource-group $resource_group_name --issuer $SERVICE_ACCOUNT_ISSUER --subject "system:serviceaccount:${SERVICE_ACCOUNT_NAMESPACE}:${SERVICE_ACCOUNT_NAME}" 

# Show the federated credential 

az identity federated-credential show --name $FedIdCredentialName --resource-group $resource_group_name --identity-name $MSIName

Примечание.

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

Шаг 4. Развертывание приложения

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

$image = "<image>"  # Replace <image> with the actual image name 
$containerName = "<containerName>"  # Replace <containerName> with the actual container name 

$yaml = @" 
apiVersion: v1 
kind: Pod 
metadata: 
  name: sample-quick-start 
  namespace: $SERVICE_ACCOUNT_NAMESPACE 
  labels: 
    azure.workload.identity/use: "true" # Required. Only pods with this label can use workload identity. 
spec: 
  serviceAccountName: $SERVICE_ACCOUNT_NAME 
  containers: 
    - image: $image 
      name: $containerName 
"@ 

# Replace variables within the YAML content 
$yaml = $yaml -replace '\$SERVICE_ACCOUNT_NAMESPACE', $SERVICE_ACCOUNT_NAMESPACE ` 
                -replace '\$SERVICE_ACCOUNT_NAME', $SERVICE_ACCOUNT_NAME 

# Apply the YAML configuration 
$yaml | kubectl apply -f -

Внимание

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

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

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

В следующем примере показано, как использовать модель управления доступом на основе ролей Azure (Azure RBAC) для предоставления pod-доступа к хранилищу ключей. Дополнительные сведения о модели разрешений Azure RBAC для Azure Key Vault см. в статье Предоставление разрешений приложениям для доступа к хранилищу ключей Azure с помощью Azure RBAC.

Создайте хранилище ключей с включенной защитой очистки и авторизацией RBAC. Вы также можете использовать существующее хранилище ключей, если оно настроено для защиты от очистки и RBAC авторизации:
```
az keyvault create --name $KVName --resource-group $resource_group_name --location $Location --enable-purge-protection --enable-rbac-authorization

# retrieve the key vault ID for role assignment
$KVId=$(az keyvault show --resource-group $resource_group_name --name $KVName --query id --output tsv)
```
Назначьте роль офицера секретов RBAC Key Vault самостоятельно, чтобы можно было создать секрет в новом хранилище ключей. Новые назначения ролей могут занять до пяти минут для распространения и обновления сервером авторизации.
```
az role assignment create --assignee-object-id $MSIPrincipalId --role "Key Vault Secrets Officer" --scope $KVId --assignee-principal-type ServicePrincipal
```

Создайте секрет в хранилище ключей:

az keyvault secret set --vault-name $KVName --name $KVSecretName --value "Hello!"

Назначьте роль пользователя секретов Key Vault управляемому удостоверению, созданному ранее. На этом шаге предоставляется разрешение на чтение секретов из хранилища ключей:
```
az role assignment create --assignee-object-id $MSIPrincipalId --role "Key Vault Secrets User" --scope $KVId --assignee-principal-type ServicePrincipal
```

Создайте переменную среды для URL-адреса хранилища ключей:

$KVUrl=$(az keyvault show --resource-group $resource_group_name --name $KVName --query properties.vaultUri --output tsv)

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

$yaml = @" 
apiVersion: v1 
kind: Pod 
metadata: 
  name: sample-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: $KVUrl 
      - name: SECRET_NAME 
        value: $KVSecretName 
  nodeSelector: 
    kubernetes.io/os: linux 
"@ 

# Replace variables within the YAML content 
$yaml = $yaml -replace '\$SERVICE_ACCOUNT_NAMESPACE', $SERVICE_ACCOUNT_NAMESPACE ` 
                -replace '\$SERVICE_ACCOUNT_NAME', $SERVICE_ACCOUNT_NAME ` 
                -replace '\$KVUrl', $KVUrl ` 
                -replace '\$KVSecretName', $KVSecretName 

# Apply the YAML configuration 
$yaml | kubectl --kubeconfig <path-to-aks-cluster-kubeconfig> apply -f -

Удалите кластер AKS Arc

Чтобы удалить кластер AKS Arc, используйте команду az aksarc delete:

az aksarc delete -n $aks_cluster_name -g $resource_group_name

Примечание.

Существует известная проблема при удалении кластера AKS Arc с ресурсами PodDisruptionBudget (PDB): возможно, удаление не удастся удалить эти ресурсы PDB. Корпорация Майкрософт знает о проблеме и работает над исправлением.

PDB устанавливается по умолчанию в кластерах AKS Arc с поддержкой учетных данных рабочей нагрузки. См. руководство по устранению неполадок для удаления кластера AKS Arc с включенной идентификацией рабочей нагрузки.

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

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

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

Развертывание и настройка удостоверения рабочей нагрузки в AKS, включенного кластером Azure Arc (предварительная версия)

Необходимые компоненты

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

Задание активной подписки

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

Шаг 1. Создание кластера AKS Arc с включенным удостоверением рабочей нагрузки

Сохранение URL-адреса издателя OIDC в переменной среды

Шаг 2. Создание учетной записи службы Kubernetes и привязка ее к управляемому удостоверению Azure

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

Шаг 3. Создание федеративных учетных данных в управляемом удостоверении для доверия издателю OIDC

Шаг 4. Развертывание приложения

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

Удалите кластер AKS Arc

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

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

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