Развертывание и настройка Идентификация рабочей нагрузки Microsoft Entra в кластере Azure Kubernetes Service (AKS)

• Terraform установлен локально. Инструкции по установке см. в разделе "Установка Terraform".
• Переменная среды ARM_SUBSCRIPTION_ID установлена в значение идентификатора подписки, в которой вы хотите создать ресурсы. AzureRM 4.x требует идентификатор подписки для операций планирования и применения.

Создание файла конфигурации Terraform

Файл main.tf содержит определения кластера AKS, управляемой идентичности, учетных данных федеративной идентификации, Azure Key Vault и ресурсов Kubernetes, используемых для настройки и проверки Workload ID в Microsoft Entra.

1. Создайте файл с именем main.tf и добавьте следующий код, чтобы определить версию Terraform и указать поставщика Azure:

   terraform {
    required_version = ">= 1.5.0"
    required_providers {
      azurerm = {
        source  = "hashicorp/azurerm"
        version = "~> 4.0"
      }
      kubernetes = {
        source  = "hashicorp/kubernetes"
        version = "~> 2.30"
      }
      random = {
        source  = "hashicorp/random"
        version = "~> 3.6"
      }
    }
   }
   provider "azurerm" {
    features {}
   }
   data "azurerm_client_config" "current" {}
   

2. Добавьте следующий код для main.tf определения повторно используемых переменных и создания уникальных имен для всех ресурсов:

   resource "random_string" "suffix" {
    length  = 6
    upper   = false
    special = false
    numeric = true
   }
   locals {
    suffix = random_string.suffix.result
    resource_group_name       = "rg-aks-wi-${local.suffix}"
    cluster_name              = "akswi${local.suffix}"
    managed_identity_name     = "uami-wi-${local.suffix}"
    federated_credential_name = "fic-wi-${local.suffix}"
    key_vault_name            = lower(substr("kvwi${local.suffix}", 0, 24))
    secret_name               = "secret-${local.suffix}"
    service_account_name      = "workload-sa-${local.suffix}"
    service_account_namespace = "default"
    workload_identity_subject = "system:serviceaccount:${local.service_account_namespace}:${local.service_account_name}"
   }
   

Создайте группу ресурсов с помощью команды az group create.

export RANDOM_ID="$(openssl rand -hex 3)"
export RESOURCE_GROUP="myResourceGroup$RANDOM_ID"
export LOCATION="<your-preferred-region>"
az group create --name "${RESOURCE_GROUP}" --location "${LOCATION}"

Добавьте следующий код в main.tf для создания группы ресурсов Azure. Обновите значение location, чтобы соответствовать предпочтительному Azure региону.

resource "azurerm_resource_group" "this" {
 name     = local.resource_group_name
 location = "eastus"
}

Получите URL-адрес издателя OIDC с помощью az aks show команды и сохраните его в переменной среды.

export AKS_OIDC_ISSUER="$(az aks show --name "${CLUSTER_NAME}" \
    --resource-group "${RESOURCE_GROUP}" \
    --query "oidcIssuerProfile.issuerUrl" \
    --output 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, который является случайным образом созданным и неизменяемым GUID для каждого кластера.

Добавьте следующий код в main.tf, чтобы получить URL издателя OIDC:

output "oidc_issuer_url" {
 value = azurerm_kubernetes_cluster.this.oidc_issuer_url
}

1. Получите идентификатор подписки и сохраните его в переменную среды с помощью az account show команды.

   export SUBSCRIPTION="$(az account show --query id --output tsv)"
   

2. Создайте пользовательское управляемое удостоверение с помощью команды az identity create.

   export USER_ASSIGNED_IDENTITY_NAME="myIdentity$RANDOM_ID"
   az identity create \
       --name "${USER_ASSIGNED_IDENTITY_NAME}" \
       --resource-group "${RESOURCE_GROUP}" \
       --location "${LOCATION}" \
       --subscription "${SUBSCRIPTION}"
   

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

   {
     "clientId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
     "id": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourcegroups/myResourceGroupxxxxxx/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myIdentityxxxxxx",
     "location": "eastus",
     "name": "myIdentityxxxxxx",
     "principalId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
     "resourceGroup": "myResourceGroupxxxxxx",
     "systemData": null,
     "tags": {},
     "tenantId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
     "type": "Microsoft.ManagedIdentity/userAssignedIdentities"
   }
   

3. Извлеките идентификатор клиента идентификации под управлением и сохраните его в переменной среды с помощью команды az identity show.

   export USER_ASSIGNED_CLIENT_ID="$(az identity show \
       --resource-group "${RESOURCE_GROUP}" \
       --name "${USER_ASSIGNED_IDENTITY_NAME}" \
       --query 'clientId' \
       --output tsv)"
   

Добавьте следующий код в main.tf, чтобы создать управляемое удостоверение.

resource "azurerm_user_assigned_identity" "this" {
 name                = local.managed_identity_name
 location            = azurerm_resource_group.this.location
 resource_group_name = azurerm_resource_group.this.name
}

1. Подключитесь к вашему кластеру AKS, используя команду az aks get-credentials.

   az aks get-credentials --name "${CLUSTER_NAME}" --resource-group "${RESOURCE_GROUP}"
   

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

   export SERVICE_ACCOUNT_NAME="workload-identity-sa$RANDOM_ID"
   export SERVICE_ACCOUNT_NAMESPACE="default"
   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
   

1. Добавьте следующий код в main.tf, чтобы настроить доступ к Kubernetes для разрешения создания ресурсов Kubernetes.

   data "azurerm_kubernetes_cluster" "this" {
    name                = azurerm_kubernetes_cluster.this.name
    resource_group_name = azurerm_resource_group.this.name
   }
   provider "kubernetes" {
    host                   = data.azurerm_kubernetes_cluster.this.kube_config[0].host
    client_certificate     = base64decode(data.azurerm_kubernetes_cluster.this.kube_config[0].client_certificate)
    client_key             = base64decode(data.azurerm_kubernetes_cluster.this.kube_config[0].client_key)
    cluster_ca_certificate = base64decode(data.azurerm_kubernetes_cluster.this.kube_config[0].cluster_ca_certificate)
   }
   

2. Добавьте следующий код в main.tf, чтобы создать учетную запись службы Kubernetes и аннотировать её идентификатором клиента управляемого удостоверения.

   resource "kubernetes_service_account" "this" {
    metadata {
      name      = local.service_account_name
      namespace = local.service_account_namespace
      annotations = {
        "azure.workload.identity/client-id" = azurerm_user_assigned_identity.this.client_id
      }
    }
   }
   

Создайте учетные данные для федеративной идентификации между управляемым удостоверением, издателем учетной записи службы и субъектом с помощью команды az identity federated-credential create.

export FEDERATED_IDENTITY_CREDENTIAL_NAME="myFedIdentity$RANDOM_ID"
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

Добавьте следующий код в main.tf, чтобы создать учетные данные федеративной идентичности между управляемым удостоверением, издателем учетной записи службы и объектом.

resource "azurerm_federated_identity_credential" "this" {
 name                = local.federated_credential_name
 resource_group_name = azurerm_resource_group.this.name
 parent_id           = azurerm_user_assigned_identity.this.id
 issuer              = azurerm_kubernetes_cluster.this.oidc_issuer_url
 subject             = local.workload_identity_subject
 audience            = ["api://AzureADTokenExchange"]
}

1. Создайте хранилище ключей с защитой от очистки и авторизацией Azure RBAC, включенной с помощью команды az keyvault create. Вы также можете использовать существующее хранилище ключей, если оно сконфигурировано для защиты от удаления и авторизации с помощью Azure RBAC.

   export KEYVAULT_NAME="kv-workload-id$RANDOM_ID"
   az keyvault create \
       --name "${KEYVAULT_NAME}" \
       --resource-group "${RESOURCE_GROUP}" \
       --location "${LOCATION}" \
       --enable-purge-protection \
       --enable-rbac-authorization
   

2. Получите идентификатор ресурса хранилища ключей и сохраните его в переменную среды с помощью az keyvault show команды.

   export KEYVAULT_RESOURCE_ID=$(az keyvault show --resource-group "${RESOURCE_GROUP}" \
       --name "${KEYVAULT_NAME}" \
       --query id \
       --output tsv)
   

Добавьте следующий код в main.tf, чтобы создать хранилище ключей с защитой от принудительного удаления и включенной авторизацией Azure RBAC:

resource "azurerm_key_vault" "this" {
 name                       = local.key_vault_name
 location                   = azurerm_resource_group.this.location
 resource_group_name        = azurerm_resource_group.this.name
 tenant_id                  = data.azurerm_client_config.current.tenant_id
 sku_name                   = "standard"
 enable_rbac_authorization  = true
 purge_protection_enabled   = true
}

1. Получите идентификатор вызывающего объекта и сохраните его в переменной среды с помощью команды az ad signed-in-user show.

   export CALLER_OBJECT_ID=$(az ad signed-in-user show --query id -o tsv)
   

2. Назначьте себе роль Key Vault Secrets Officer в Azure RBAC, чтобы создать секрет в новом az role assignment create с помощью команды az role assignment create.

   az role assignment create --assignee "${CALLER_OBJECT_ID}" \
       --role "Key Vault Secrets Officer" \
       --scope "${KEYVAULT_RESOURCE_ID}"
   

   Внимание

   Назначения ролей Azure могут распространяться в течение 10 минут. Если при создании секрета в следующем разделе возникает ошибка 403, подождите, пока назначение роли не вступит в силу, а затем повторите команду. Дополнительные сведения см. в разделе Troubleshoot Azure RBAC.

Добавьте следующий код в main.tf, чтобы назначить себе роль Azure RBAC Key Vault Secrets Officer, чтобы создать секрет в новом хранилище ключей и назначить роль Key Vault Secrets User управляемому удостоверению, назначаемому пользователем.

resource "azurerm_role_assignment" "user" {
 scope                = azurerm_key_vault.this.id
 role_definition_name = "Key Vault Secrets Officer"
 principal_id         = data.azurerm_client_config.current.object_id
}
resource "azurerm_role_assignment" "identity" {
 scope                = azurerm_key_vault.this.id
 role_definition_name = "Key Vault Secrets User"
 principal_id         = azurerm_user_assigned_identity.this.principal_id
}

1. Создайте секрет в хранилище ключей с помощью az keyvault secret set команды.

   Создайте секрет, имя которого хранится в переменной KEYVAULT_SECRET_NAME , и задайте его значение Hello! в созданном хранилище ключей.

   export KEYVAULT_SECRET_NAME="my-secret$RANDOM_ID"
   az keyvault secret set \
       --vault-name "${KEYVAULT_NAME}" \
       --name "${KEYVAULT_SECRET_NAME}" \
       --value 'Hello!'
   

2. Получите идентификатор безопасности управляемой удостоверенности, назначаемой пользователем, и сохраните его в переменной окружения с помощью команды az identity show.

   export IDENTITY_PRINCIPAL_ID=$(az identity show \
       --name "${USER_ASSIGNED_IDENTITY_NAME}" \
       --resource-group "${RESOURCE_GROUP}" \
       --query principalId \
       --output tsv)
   

3. Назначьте роль пользователя секретов Key Vault управляемому удостоверению, назначенному пользователем, с помощью команды az role assignment create. Этот шаг предоставляет управляемому удостоверению разрешение на чтение секретов из хранилища ключей.

   az role assignment create \
       --assignee-object-id "${IDENTITY_PRINCIPAL_ID}" \
       --role "Key Vault Secrets User" \
       --scope "${KEYVAULT_RESOURCE_ID}" \
       --assignee-principal-type ServicePrincipal
   

4. Создайте переменную среды для URL-адреса хранилища ключей с помощью az keyvault show команды.

   export KEYVAULT_URL="$(az keyvault show \
       --resource-group "${RESOURCE_GROUP}" \
       --name ${KEYVAULT_NAME} \
       --query properties.vaultUri \
       --output tsv)"
   

Добавьте следующий код main.tf, чтобы создать секрет в хранилище ключей:

resource "azurerm_key_vault_secret" "this" {
 name         = local.secret_name
 value        = "Hello from Key Vault"
 key_vault_id = azurerm_key_vault.this.id

 depends_on = [azurerm_role_assignment.user]
}

Разверните проверочный pod и проверьте доступ (Azure CLI)

1. Разверните pod, чтобы подтвердить, что идентификатор рабочей нагрузки может получить доступ к секрету в хранилище ключей. В следующем примере используется образ ghcr.io/azure/azure-workload-identity/msal-go, содержащий пример приложения, который извлекает секрет из Azure Key Vault с помощью Идентификация рабочей нагрузки Microsoft Entra:

   kubectl apply -f - <<EOF
   apiVersion: v1
   kind: Pod
   metadata:
       name: sample-workload-identity-key-vault
       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
   

2. Подождите, пока pod будет в состоянии Ready с помощью команды kubectl wait.

   kubectl wait --namespace ${SERVICE_ACCOUNT_NAMESPACE} --for=condition=Ready pod/sample-workload-identity-key-vault --timeout=120s
   

3. Убедитесь, что переменная среды SECRET_NAME задана в поде с помощью команды kubectl describe.

   kubectl describe pod sample-workload-identity-key-vault | grep "SECRET_NAME:"
   

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

   SECRET_NAME: ${KEYVAULT_SECRET_NAME}
   

4. Убедитесь, что pod-ы могут получить токен и доступ к ресурсу с помощью команды kubectl logs.

   kubectl logs sample-workload-identity-key-vault
   

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

   I0114 10:35:09.795900       1 main.go:63] "successfully got secret" secret="Hello!"
   

   Внимание

   Назначения ролей Azure RBAC могут занимать до 10 минут, чтобы распространиться. Если модуль pod не может получить доступ к секрету, может потребоваться ждать распространения назначения роли. Дополнительные сведения см. в разделе Troubleshoot Azure RBAC.

Отключение Идентификация рабочей нагрузки Microsoft Entra в кластере AKS

Чтобы отключить Идентификация рабочей нагрузки Microsoft Entra в кластере AKS, где вы включили и настроили его, используйте az aks update команду с параметром--disable-workload-identity.

az aks update \
    --resource-group "${RESOURCE_GROUP}" \
    --name "${CLUSTER_NAME}" \
    --disable-workload-identity

Разверните pod для проверки (Terraform)

Добавьте следующий код для main.tf развертывания модуля pod проверки, использующего удостоверение рабочей нагрузки для доступа к секрету в хранилище ключей:

resource "kubernetes_pod" "test" {
 metadata {
   name      = "workload-identity-test"
   namespace = local.service_account_namespace
   labels = {
     "azure.workload.identity/use" = "true"
   }
 }
 spec {
   service_account_name = kubernetes_service_account.this.metadata[0].name
   container {
     name  = "test"
     image = "ghcr.io/azure/azure-workload-identity/msal-go"
     env {
       name  = "KEYVAULT_URL"
       value = azurerm_key_vault.this.vault_uri
     }
     env {
       name  = "SECRET_NAME"
       value = azurerm_key_vault_secret.this.name
     }
   }
 }

 depends_on = [
   azurerm_federated_identity_credential.this,
   azurerm_role_assignment.identity,
 ]
}

Инициализируйте Terraform

Инициализируйте Terraform в каталоге, содержащем ваш файл main.tf, с помощью команды terraform init. Эта команда загружает поставщика (провайдера) Azure, необходимого для управления ресурсами Azure с помощью Terraform.

terraform init

Создайте план запуска Terraform

Создайте план выполнения Terraform с помощью terraform plan команды. Эта команда показывает ресурсы, которые Terraform создаст или изменит в подписке Azure.

terraform plan

Применение конфигурации Terraform

После проверки и подтверждения плана выполнения примените конфигурацию Terraform с помощью terraform apply команды. Эта команда создает или изменяет ресурсы, определенные в файле main.tf в подписке Azure.

terraform apply

Проверка развертывания

1. Подключитесь к вашему кластеру AKS, используя команду az aks get-credentials.

   az aks get-credentials --name <cluster-name> --resource-group <resource-group>
   

2. Проверьте состояние pod проверки с помощью команды kubectl get pods.

3. Когда модуль pod достигнет Ready состояния, убедитесь, что он может получить доступ к секрету хранилища ключей, проверив журналы pod с помощью kubectl logs команды.

   kubectl logs workload-identity-test
   

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

   I0114 10:35:09.795900       1 main.go:63] "successfully got secret" secret="Hello from Key Vault"
   

   Внимание

   Назначения ролей Azure RBAC могут занимать до 10 минут, чтобы распространиться. Если модуль pod не может получить доступ к секрету, дождитесь распространения назначения роли, а затем повторно создайте модуль pod с помощью terraform apply -replace="kubernetes_pod.test" команды. Дополнительные сведения см. в разделе Troubleshoot Azure RBAC.