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

Статья
11/16/2024

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

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

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

Внимание

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

Примечание.

В этой общедоступной предварительной версии AKS Edge Essentials позволяет включить удостоверение рабочей нагрузки во время первоначального развертывания скрипта быстрого запуска операций Интернета вещей Azure. Эта функция недоступна для других сценариев AKS Edge Essentials.

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

Прежде чем использовать федерацию удостоверений рабочей нагрузки для кластера AKS Edge Essentials, необходимо развернуть скрипт быстрого запуска операции Интернета вещей Azure, как описано в разделе "Создание и настройка кластера AKS Edge Essentials", который может выполнять операции Интернета вещей Azure. Сценарий автоматически включает функцию федерации удостоверений рабочей нагрузки в кластере 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 и заметите ее с идентификатором клиента управляемого удостоверения, созданного на предыдущем шаге. Скопируйте и вставьте следующие команды 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 -

Внимание

Убедитесь, что модули 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 $aks_cluster_name apply -f -

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

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

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