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

Применяется для: AKS на Azure Local

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

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

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

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

Предварительные условия

Перед развертыванием кластера 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: ID Azure Resource Manager кастомного местоположения. Настраиваемое расположение настраивается во время развертывания локального кластера Azure. Администратор инфраструктуры должен предоставить идентификатор расположения в менеджере ресурсов для пользовательского расположения. Вы также можете получить идентификатор 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, используя $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.

Сохраните 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 и аннотируете её с помощью ID клиента управляемого удостоверения, созданного на предыдущем шаге.

Используйте подключение к кластеру для доступа к кластеру с клиентского устройства. Дополнительные сведения см. в статье Доступ к кластеру с клиентского устройства:

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 ID.

# 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 - 

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

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

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

1. Создайте хранилище ключей с включенной защитой очистки и авторизацией 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)
   

2. Назначьте себе роль офицера секретов Key Vault RBAC, чтобы вы могли создать секрет в новом хранилище ключей. Новые назначения ролей могут занять до пяти минут для распространения и обновления сервером авторизации.

   $CALLER_OBJECT_ID=$(az ad signed-in-user show --query id -o tsv)
   
   az role assignment create --assignee-object-id $CALLER_OBJECT_ID --role "Key Vault Secrets Officer" --scope $KVId --assignee-principal-type ServicePrincipal
   

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

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

4. Назначьте управляемому удостоверению, созданному ранее, роль пользователя секретов Key Vault. На этом шаге управляемой сущности предоставляется разрешение на чтение секретов из хранилища ключей.

   $IDENTITY_PRINCIPAL_ID=$(az identity show --name "$USER_ASSIGNED_IDENTITY_NAME" --resource-group "$resource_group_name" --query principalId --output tsv)
   
   az role assignment create --assignee-object-id $IDENTITY_PRINCIPAL_ID --role "Key Vault Secrets User" --scope $KVId --assignee-principal-type ServicePrincipal
   

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

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

6. Разверните 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

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

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