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

Подключите поставщика удостоверений Azure к CSI-драйверу Azure Key Vault Secrets Store в службе Azure Kubernetes Service (AKS)

Драйвер интерфейса хранилища контейнеров хранилища секретов (CSI) в службе Azure Kubernetes (AKS) предоставляет различные методы доступа на основе удостоверений к Azure Key Vault. В этой статье описаны эти методы и рекомендации по использованию моделей безопасности на основе ролей Azure (Azure RBAC) или OpenID Connect (OIDC) для доступа к хранилищу ключей и кластеру AKS.

Вы можете использовать один из следующих методов доступа:

  • Коннектор службы с управляемым удостоверением
  • Идентификатор рабочей нагрузки
  • Управляемая идентификация, назначаемая пользователем

Узнайте, как подключиться к Azure Key Vault, используя Secrets Store CSI Driver в кластере службы Azure Kubernetes Service (AKS) с помощью Service Connector. В этой статье вы выполняете следующие задачи:

  • Создайте кластер AKS и Azure Key Vault.
  • Создайте подключение между кластером AKS и Azure Key Vault с помощью соединителя службы.
  • SecretProviderClass Создайте CRD и идентификаторPod, который использует поставщик CSI для проверки подключения.
  • Очистите ресурсы.

Prerequisites

Начальная настройка

  1. Если вы впервые используете соединитель служб, начните с запуска команды az provider register , чтобы зарегистрировать соединитель службы и поставщики ресурсов конфигурации Kubernetes.

    az provider register -n Microsoft.ServiceLinker

    az provider register -n Microsoft.KubernetesConfiguration

    Tip

    Вы можете проверить, зарегистрированы ли эти поставщики az provider show -n "Microsoft.ServiceLinker" --query registrationState ресурсов, выполнив команды и az provider show -n "Microsoft.KubernetesConfiguration" --query registrationState.

  2. При необходимости используйте команду Azure CLI, чтобы получить список поддерживаемых целевых служб для кластера AKS.

    az aks connection list-support-types --output table

Создание ресурсов Azure

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

    az group create \
    --name <resource-group-name> \
    --location <location>

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

    az aks create \
    --resource-group <resource-group-name> \
    --name <cluster-name> \
    --enable-managed-identity \
    --node-count 1

  3. Подключитесь к кластеру az aks get-credentials с помощью команды.

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

  4. Создайте хранилище ключей Azure с помощью az keyvault create команды.

    az keyvault create \
    --resource-group <resource-group-name> \  
    --name <key-vault-name> \
    --location <location>

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

    az keyvault secret set \
    --vault-name <key-vault-name> \
    --name <secret-name> \
    --value <secret-value>

Создание подключения к службе в AKS с помощью Service Connector

Вы можете создать подключение службы к Azure Key Vault с помощью портала Azure или Azure CLI.

  1. В портал Azure перейдите к ресурсу кластера AKS.

  2. В меню службы в разделе "Параметры" выберите "Соединитель службы>Создать.

  3. На странице "Создание подключения" настройте следующие параметры на вкладке "Основные сведения".

    • Пространство имен Kubernetes: выберите default.
    • Тип службы: выберите Key Vault и установите флажок, чтобы включить поставщик CSI Azure Key Vault.
    • Имя подключения: введите имя подключения.
    • Подписка. Выберите подписку, содержащую хранилище ключей.
    • Хранилище ключей: выберите созданное хранилище ключей.
    • Тип клиента: select None.

  4. Выберите "Проверка + создание", а затем Создать, чтобы создать подключение.

Проверка подключения

Клонирование примера репозитория и развертывание файлов манифеста

  1. Клонируйте пример репозитория с помощью git clone команды.

    git clone https://github.com/Azure-Samples/serviceconnector-aks-samples.git

  2. Измените каталоги на пример поставщика CSI в Azure Key Vault.

    cd serviceconnector-aks-samples/azure-keyvault-csi-provider

  3. secret_provider_class.yaml В файле замените следующие заполнители данными Azure Key Vault:

    • Замените <AZURE_KEYVAULT_NAME> именем созданного и подключенного хранилища ключей.
    • Замените <AZURE_KEYVAULT_TENANTID> идентификатором клиента хранилища ключей.
    • Замените <AZURE_KEYVAULT_CLIENTID> на идентификатор клиента идентификации надстройки azureKeyvaultSecretsProvider.
    • Замените <KEYVAULT_SECRET_NAME>, который вы создали, на секрет хранилища ключей. Например: ExampleSecret.

  4. Разверните SecretProviderClass CRD с помощью команды kubectl apply.

    kubectl apply -f secret_provider_class.yaml

  5. Разверните файл манифеста Pod с помощью команды kubectl apply.

    Команда создает pod с именем sc-demo-keyvault-csi в пространстве имен по умолчанию кластера AKS.

    kubectl apply -f pod.yaml

Проверка подключения

  1. Убедитесь, что pod был успешно создан с помощью команды kubectl get.

    kubectl get pod/sc-demo-keyvault-csi

    После запуска пода подключённое содержимое по пути тома, указанному в YAML развертывания, становится доступным.

  2. Отображение секретов в хранилище секретов с помощью kubectl exec команды.

    kubectl exec sc-demo-keyvault-csi -- ls /mnt/secrets-store/

  3. Отобразите секрет с помощью команды kubectl exec.

    В этом примере команды отображён тестовый секрет с именем ExampleSecret.

    kubectl exec sc-demo-keyvault-csi -- cat /mnt/secrets-store/ExampleSecret

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

Доступ с помощью идентификатора рабочей нагрузки Microsoft Entra

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

В этой модели безопасности кластер AKS выступает в качестве издателя маркеров. Затем Microsoft Entra ID использует OIDC для обнаружения открытых ключей подписи и проверки подлинности токена учетной записи службы перед его обменом на токен Microsoft Entra. Чтобы рабочая нагрузка обменяла токен учетной записи службы, спроецированный в его том, на токен Microsoft Entra, вам потребуется библиотека клиента удостоверений Azure в Azure SDK или библиотека Microsoft Authentication Library (MSAL).

Note

  • Этот метод проверки подлинности заменяет управляемое модулем Microsoft Entra pod (предварительная версия). Управляемая подом идентификация Microsoft Entra с открытым исходным кодом (предварительно) в службе Azure Kubernetes была признана устаревшей с 24 октября 2022 года.
  • Идентификатор рабочей нагрузки Microsoft Entra поддерживает кластеры Windows и Linux.

Настройка идентификации рабочей нагрузки

  1. Настройте свою подписку с помощью команды az account set.

    export SUBSCRIPTION_ID=<subscription id>
export RESOURCE_GROUP=<resource group name>
export UAMI=<name for user assigned identity>
export KEYVAULT_NAME=<existing keyvault name>
export CLUSTER_NAME=<aks cluster name>

az account set --subscription $SUBSCRIPTION_ID

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

    Note

    На этом этапе предполагается, что у вас есть существующий кластер AKS с включенной идентификацией рабочей нагрузки. Если удостоверение личности рабочей нагрузки не включено, см. статью "Включить удостоверение личности рабочей нагрузки в существующем кластере AKS", чтобы включить его.

    az identity create --name $UAMI --resource-group $RESOURCE_GROUP

export USER_ASSIGNED_CLIENT_ID="$(az identity show --resource-group $RESOURCE_GROUP --name $UAMI --query 'clientId' -o tsv)"
export IDENTITY_TENANT=$(az aks show --name $CLUSTER_NAME --resource-group $RESOURCE_GROUP --query identity.tenantId -o tsv)

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

    Important

    • Если ваше хранилище ключей настроено с --enable-rbac-authorization и вы используете тип key или certificate, назначьте роль Key Vault Certificate User для предоставления разрешений.
    • Если ваше хранилище ключей настроено с --enable-rbac-authorization и вы используете тип secret, назначьте роль Key Vault Secrets User.
    • Если хранилище ключей не задано --enable-rbac-authorization, можно использовать команду az keyvault set-policy с параметром --key-permissions get, --certificate-permissions get или параметром --secret-permissions get для создания политики хранилища ключей, чтобы предоставить доступ к ключам, сертификатам или секретам. Рассмотрим пример.
    az keyvault set-policy --name $KEYVAULT_NAME --key-permissions get --object-id $IDENTITY_OBJECT_ID

    export KEYVAULT_SCOPE=$(az keyvault show --name $KEYVAULT_NAME --query id -o tsv)

# Example command for key vault with Azure RBAC enabled using `key` type
az role assignment create --role "Key Vault Certificate User" --assignee $USER_ASSIGNED_CLIENT_ID --scope $KEYVAULT_SCOPE

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

    Note

    На этом шаге предполагается, что у вас есть существующий кластер AKS с включенным URL-адресом издателя OIDC. Если URL-адрес издателя OIDC не включен, см. раздел 'Обновление кластера AKS с издателем OIDC', чтобы включить его.

    export AKS_OIDC_ISSUER="$(az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query "oidcIssuerProfile.issuerUrl" -o tsv)"
echo $AKS_OIDC_ISSUER

  5. Создайте учетные данные федеративного удостоверения между приложением Microsoft Entra, издателем учетной записи службы и субъектом. Получите идентификатор объекта приложения Microsoft Entra с помощью следующих команд. Убедитесь, что вы обновили значения serviceAccountName для имени учетной записи службы Kubernetes и serviceAccountNamespace для его пространства имен.

    export SERVICE_ACCOUNT_NAME="workload-identity-sa"  # sample name; can be changed
export SERVICE_ACCOUNT_NAMESPACE="default" # can be changed to namespace of your workload

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

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

    export FEDERATED_IDENTITY_NAME="aksfederatedidentity" # can be changed as needed

az identity federated-credential create --name $FEDERATED_IDENTITY_NAME --identity-name $UAMI --resource-group $RESOURCE_GROUP --issuer ${AKS_OIDC_ISSUER} --subject system:serviceaccount:${SERVICE_ACCOUNT_NAMESPACE}:${SERVICE_ACCOUNT_NAME}

  7. Разверните SecretProviderClass с помощью команды kubectl apply и следующего YAML скрипта.

    cat <<EOF | kubectl apply -f -
# This is a SecretProviderClass example using workload identity to access your key vault
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: azure-kvname-wi # needs to be unique per namespace
spec:
  provider: azure
  parameters:
    usePodIdentity: "false"
    clientID: "${USER_ASSIGNED_CLIENT_ID}" # Setting this to use workload identity
    keyvaultName: ${KEYVAULT_NAME}       # Set to the name of your key vault
    cloudName: ""                         # [OPTIONAL for Azure] if not provided, the Azure environment defaults to AzurePublicCloud
    objects:  |
      array:
        - |
          objectName: secret1             # Set to the name of your secret
          objectType: secret              # object types: secret, key, or cert
          objectVersion: ""               # [OPTIONAL] object versions, default to latest if empty
        - |
          objectName: key1                # Set to the name of your key
          objectType: key
          objectVersion: ""
    tenantId: "${IDENTITY_TENANT}"        # The tenant ID of the key vault
EOF

    Note

    Если вы используете objectAlias вместо objectName, обновите скрипт YAML, чтобы учесть это.

    Note

    Для того чтобы SecretProviderClass работал правильно, обязательно заполните хранилище ключей Azure секретами, ключами или сертификатами до того, как ссылаться на них в разделе objects.

  8. Разверните пример pod с помощью команды kubectl apply и следующего YAML-скрипта.

    cat <<EOF | kubectl apply -f -
# This is a sample pod definition for using SecretProviderClass and workload identity to access your key vault
kind: Pod
apiVersion: v1
metadata:
  name: busybox-secrets-store-inline-wi
  labels:
    azure.workload.identity/use: "true"
spec:
  serviceAccountName: "workload-identity-sa"
  containers:
    - name: busybox
      image: registry.k8s.io/e2e-test-images/busybox:1.29-4
      command:
        - "/bin/sleep"
        - "10000"
      volumeMounts:
      - name: secrets-store01-inline
        mountPath: "/mnt/secrets-store"
        readOnly: true
  volumes:
    - name: secrets-store01-inline
      csi:
        driver: secrets-store.csi.k8s.io
        readOnly: true
        volumeAttributes:
          secretProviderClass: "azure-kvname-wi"
EOF

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

Доступ с помощью управляемого удостоверения

Управляемый идентификатор Microsoft Entra — это удостоверение, которое администратор использует для проверки подлинности в других службах Azure. Управляемая идентификация использует Azure RBAC для федерации с внешними поставщиками удостоверений.

В этой модели безопасности вы можете предоставить доступ к ресурсам вашего кластера участникам команды или арендаторам, имеющим управляемую роль. Роль проверяется на предмет прав доступа к keyvault и другим учетным данным. Когда вы активировали провайдера Azure Key Vault для драйвера CSI Хранилища секретов в вашем кластере AKS, была создана учетная запись пользователя.

Настройка управляемого удостоверения

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

    az aks show --resource-group <resource-group> --name <cluster-name> --query addonProfiles.azureKeyvaultSecretsProvider.identity.objectId -o tsv
az aks show --resource-group <resource-group> --name <cluster-name> --query addonProfiles.azureKeyvaultSecretsProvider.identity.clientId -o tsv

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

    az identity create --resource-group <resource-group> --name <identity-name>
az vmss identity assign --resource-group <resource-group> --name <agent-pool-vmss> --identities <identity-resource-id>
az vm identity assign --resource-group <resource-group> --name <agent-pool-vm> --identities <identity-resource-id>

az identity show --resource-group <resource-group> --name <identity-name> --query 'clientId' -o tsv

  2. Создайте назначение ролей, которое предоставляет удостоверению разрешение на доступ к секретам хранилища ключей, ключам доступа и сертификатам с помощью az role assignment create команды.

    Important

    • Если ваше хранилище ключей настроено с --enable-rbac-authorization, и вы используете тип key или certificate, назначьте роль Key Vault Certificate User.
    • Если ваше хранилище ключей настроено с --enable-rbac-authorization и вы используете тип secret, назначьте роль Key Vault Secrets User.
    • Если хранилище ключей не задано --enable-rbac-authorization, можно использовать команду az keyvault set-policy с параметром --key-permissions get, --certificate-permissions get или параметром --secret-permissions get для создания политики хранилища ключей, чтобы предоставить доступ к ключам, сертификатам или секретам. Рассмотрим пример.
    az keyvault set-policy --name $KEYVAULT_NAME --key-permissions get --object-id $IDENTITY_OBJECT_ID

    export IDENTITY_OBJECT_ID="$(az identity show --resource-group <resource-group> --name <identity-name> --query 'principalId' -o tsv)"
export KEYVAULT_SCOPE=$(az keyvault show --name <key-vault-name> --query id -o tsv)

# Example command for key vault with Azure RBAC enabled using `key` type
az role assignment create --role "Key Vault Certificate User" --assignee $USER_ASSIGNED_CLIENT_ID --scope $KEYVAULT_SCOPE

  3. Создайте SecretProviderClass, используя следующий YAML. Обязательно используйте собственные значения для userAssignedIdentityID, keyvaultNametenantIdи объектов для получения из хранилища ключей.

    # This is a SecretProviderClass example using user-assigned identity to access your key vault
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: azure-kvname-user-msi
spec:
  provider: azure
  parameters:
    usePodIdentity: "false"
    useVMManagedIdentity: "true"          # Set to true for using managed identity
    userAssignedIdentityID: <client-id>   # Set the clientID of the user-assigned managed identity to use
    keyvaultName: <key-vault-name>        # Set to the name of your key vault
    cloudName: ""                         # [OPTIONAL for Azure] if not provided, the Azure environment defaults to AzurePublicCloud
    objects:  |
      array:
        - |
          objectName: secret1
          objectType: secret              # object types: secret, key, or cert
          objectVersion: ""               # [OPTIONAL] object versions, default to latest if empty
        - |
          objectName: key1
          objectType: key
          objectVersion: ""
    tenantId: <tenant-id>                 # The tenant ID of the key vault

    Note

    Если вы objectAlias используете вместо этого objectName, обязательно обновите скрипт YAML.

    Note

    Для того чтобы SecretProviderClass работал правильно, обязательно заполните хранилище ключей Azure секретами, ключами или сертификатами до того, как ссылаться на них в разделе objects.

  4. Примените SecretProviderClass к вашему кластеру с помощью команды kubectl apply.

    kubectl apply -f secretproviderclass.yaml

  5. Создайте pod с помощью следующего YAML.

    # This is a sample pod definition for using SecretProviderClass and the user-assigned identity to access your key vault
kind: Pod
apiVersion: v1
metadata:
  name: busybox-secrets-store-inline-user-msi
spec:
  containers:
    - name: busybox
      image: registry.k8s.io/e2e-test-images/busybox:1.29-4
      command:
        - "/bin/sleep"
        - "10000"
      volumeMounts:
      - name: secrets-store01-inline
        mountPath: "/mnt/secrets-store"
        readOnly: true
  volumes:
    - name: secrets-store01-inline
      csi:
        driver: secrets-store.csi.k8s.io
        readOnly: true
        volumeAttributes:
          secretProviderClass: "azure-kvname-user-msi"

  6. Примените pod к вашему кластеру, используя команду kubectl apply.

    kubectl apply -f pod.yaml

Проверка секретов Key Vault

После запуска пода подключённое содержимое по пути тома, указанному в YAML развертывания, становится доступным. Используйте следующие команды, чтобы проверить секреты и отобразить тестовый секрет.

  1. Отображение секретов, содержащихся в хранилище секретов, с помощью следующей команды.

    kubectl exec busybox-secrets-store-inline-user-msi -- ls /mnt/secrets-store/

  2. Покажите секрет в хранилище, используя следующую команду. В этом примере команды показан секрет ExampleSecretтеста.

    kubectl exec busybox-secrets-store-inline-user-msi -- cat /mnt/secrets-store/ExampleSecret

Получение сертификатов и ключей

Дизайн Azure Key Vault делает резкие различия между ключами, секретами и сертификатами. Функции сертификата службы Key Vault предназначены для использования возможностей ключа и секретов. При создании сертификата хранилища ключей он создает адресный ключ и секрет с тем же именем. Этот ключ позволяет выполнять операции проверки подлинности, а секрет позволяет получить значение сертификата в виде секрета.

Сертификат хранилища ключей также содержит общедоступные метаданные сертификата x509. Хранилище ключей хранит как общедоступные, так и частные компоненты сертификата в секрете. Вы можете получить каждый отдельный компонент, указав параметр objectType в SecretProviderClass. В следующей таблице показаны объекты, сопоставленные с различными ресурсами, связанными с сертификатом:

Object Возвращаемое значение Возвращает всю цепочку сертификатов
key Открытый ключ в формате "Улучшенная конфиденциальность почты" (PEM). N/A
cert Сертификат в формате PEM. No
secret Закрытый ключ и сертификат в формате PEM. Yes

Отключите надстройку в существующих кластерах

Note

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

Отключите поставщика Azure Key Vault для функции драйвера CSI хранилища секретов в существующем кластере, используя команду az aks disable-addons с надстройкой azure-keyvault-secrets-provider.

az aks disable-addons --addons azure-keyvault-secrets-provider --resource-group myResourceGroup --name myAKSCluster

Note

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

Дальнейшие шаги

Из этой статьи вы узнали, как создать и предоставить удостоверение для доступа к Azure Key Vault. Интеграция соединителя служб помогает упростить конфигурацию подключения для рабочих нагрузок AKS и служб резервного копирования Azure. Он безопасно обрабатывает проверку подлинности и конфигурации сети и следует рекомендациям по подключению к службам Azure. Дополнительные сведения см. в статье "Использование поставщика Azure Key Vault для драйвера CSI хранилища секретов" в кластере AKS и вводные сведения о соединителе службы.

Если вы хотите настроить дополнительные параметры конфигурации или выполнить устранение проблем, ознакомьтесь с параметрами конфигурации и ресурсами для поставщика Key Vault Azure с драйвером CSI Secrets Store в AKS.

  • Last updated on