Бөлісу құралы:

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

  • Мақала

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

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

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

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

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

Внимание

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

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

Создание ресурсов 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 с помощью соединителя службы (предварительная версия)

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

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

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

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

    • Пространство имен Kubernetes: выберите значение по умолчанию.
    • Тип службы: выберите 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, таких как рабочие нагрузки в программном обеспечении. Драйвер CSI хранилища секретов интегрируется с собственными возможностями Kubernetes для федерации с внешними поставщиками удостоверений.

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

Примечание.

  • Этот метод проверки подлинности заменяет управляемое модулем Microsoft Entra pod (предварительная версия). Управляемое модулем открытый код Microsoft Entra pod (предварительная версия) в Служба Azure Kubernetes устарело по состоянию на 10.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 команды.

    Примечание.

    На этом шаге предполагается, что у вас есть существующий кластер 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 команды.

    Внимание

    • Если хранилище ключей задано, --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 RBAC enabled using `key` type
az role assignment create --role "Key Vault Certificate User" --assignee $USER_ASSIGNED_CLIENT_ID --scope $KEYVAULT_SCOPE

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

    Примечание.

    На этом шаге предполагается, что у вас есть существующий кластер AKS с включенным 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

    Примечание.

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

    Примечание.

    Чтобы SecretProviderClass обеспечить правильную работу, обязательно заполните Azure Key Vault секретами, ключами или сертификатами, прежде чем ссылаться на них в 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. Управляемое удостоверение использует 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 команды.

    Внимание

    • Если хранилище ключей задано, --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 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

    Примечание.

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

    Примечание.

    Чтобы SecretProviderClass обеспечить правильную работу, обязательно заполните Azure Key Vault секретами, ключами или сертификатами, прежде чем ссылаться на них в 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). Н/П
cert Сертификат в формате PEM. No
secret Закрытый ключ и сертификат в формате PEM. Да

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

Примечание.

Прежде чем отключить надстройку, убедитесь, что он не 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

Примечание.

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

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

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

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