Настройка удостоверения рабочей нагрузки в кластере AKS Edge Essentials (предварительная версия)

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

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

Общие сведения о федерации удостоверений рабочей нагрузки см. в статье "Федерация удостоверений рабочей нагрузки" в Kubernetes с поддержкой Azure Arc (предварительная версия). Рекомендуется установить диспетчер ключей для Kubernetes в кластере AKS Edge Essentials (предварительный просмотр) для автоматического обновления ключей подписывания, которые выдают токены учетных записей служб Kubernetes.

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

Прежде чем использовать федерацию идентификации для кластера AKS Edge Essentials, необходимо развернуть скрипт быстрого старта Azure IoT Operations, как описано в разделе "Создание и настройка кластера AKS Edge Essentials, который может выполнять операции Azure IoT Operations". Сценарий автоматически включает функцию федерации удостоверений рабочей нагрузки в кластере AKS Edge Essentials.

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

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/", 

# workloadIdentity "enabled": true 
"securityProfile": { 
    "workloadIdentity": { 
      "enabled": true

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

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

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

$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" 

# Include these variables to access key vault secrets from a pod in the cluster. 
$KVName = "KV-workload-id" 
$KVSecretName= "KV-secret"

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

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

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

Шаг 1. Создание учетной записи службы 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 и добавьте аннотацию с идентификатором клиента (Client ID) управляемого удостоверения, которое вы создали на предыдущем шаге. Скопируйте и вставьте следующие команды Azure CLI:

$yaml = @" 
apiVersion: v1 
kind: ServiceAccount 
metadata: 
  annotations: 
    azure.workload.identity/client-id: $MSIId 
  name: $SERVICE_ACCOUNT_NAME 
  namespace: $SERVICE_ACCOUNT_NAMESPACE 
"@ 

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

# Apply the YAML content to Kubernetes 
$yaml | kubectl apply -f -

Следующие выходные данные показывают, что удостоверение рабочей нагрузки успешно создано:

serviceaccount/workload-identity-sa created

Шаг 2. Создание федеративных учетных данных в управляемом удостоверении для доверия издателю 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

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

При развертывании 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 Secrets Officer RBAC, чтобы вы могли создать секрет в новом хранилище ключей. Новые назначения ролей могут занять до пяти минут для распространения и обновления сервером авторизации.

   az role assignment create --assignee-object-id $MSIPrincipalId --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 Secrets User управляемому удостоверению, созданному ранее. Этот шаг даёт управляемой идентичности разрешение на чтение секретов из хранилища ключей.

   az role assignment create --assignee-object-id $MSIPrincipalId --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 $aks_cluster_name apply -f -
   

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

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

Если вы не установили Диспетчер ключей для Kubernetes в кластере AKS Edge Essentials (предварительная версия), следуйте инструкциям в этой статье, чтобы обеспечить периодическую ротацию токена.