Устранение неполадок с надстройкой поставщика секретов Azure Key Vault в AKS

Статья
12/13/2024

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

Примечание.

Эта статья относится к управляемой надстройке AKS поставщика секретов Azure Key Vault. Если вы используете установленную (самоуправляемую) версию helm, перейдите к документации по поставщику Хранилища ключей Azure для хранилища секретов CSI Driver GitHub.

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

Azure CLI
Средство Kubernetes kubectl (чтобы установить kubectl с помощью Azure CLI, выполните команду az aks install-cli .)
Надстройка драйвера CSI хранилища секретов Kubernetes, включенная в кластере AKS
Средство URL-адреса клиента (curl)
Средство командной строки Netcat (nc) для TCP-подключений

Контрольный список по устранению неполадок

Шаг 1. Убедитесь, что в кластере включена надстройка поставщика секретов Azure Key Vault.

Выполните команду az aks show, чтобы убедиться, что надстройка включена в кластере:

az aks show -g <aks-resource-group-name> -n <aks-name> --query 'addonProfiles.azureKeyvaultSecretsProvider'

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

{
  "config": null,
  "enabled": true,
  "identity": {
    "clientId": "<client-id>",
    "objectId": "<object-id>",
    "resourceId": "/subscriptions/<subscription-id>/resourcegroups/<resource-group-name>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<azure-key-vault-secrets-provider-identity-name>"
  }
}

enabled Если флаг показан, как false показано в предыдущих выходных данных, надстройка поставщика секретов Azure Key Vault не включена в кластере. В этом случае ознакомьтесь с документацией по поставщику Azure Key Vault для хранилища секретов CSI Driver GitHub для дальнейшего устранения неполадок.

enabled Если флаг показан, как true показано в предыдущих выходных данных, надстройка поставщика секретов Azure Key Vault включена в кластере. В этом случае перейдите к следующим шагам в этой статье.

Шаг 2. Проверка журналов поставщика хранилища секретов и журналов pod драйвера CSI

Журналы надстроек поставщика секретов Azure Key Vault создаются как поставщиками, так и модулями pod драйверов. Чтобы устранить неполадки, влияющие на поставщика или драйвера, изучите журналы из модуля pod, работающего на том же узле, что и модуль pod приложения.

Выполните команду get kubectl, чтобы найти модули pod поставщика хранилища секретов и драйвера CSI, которые выполняются на том же узле, на котором выполняется модуль pod приложения:
```
kubectl get pod -l 'app in (secrets-store-provider-azure, secrets-store-csi-driver)' -n kube-system -o wide
```
Выполните команду kubectl logs, чтобы просмотреть журналы из pod поставщика хранилища секретов:
```
kubectl logs -n kube-system <provider-pod-name> --since=1h | grep ^E
```
Выполните команду kubectl logs, чтобы просмотреть журналы из pod драйвера CSI хранилища секретов:
```
kubectl logs -n kube-system <csi-driver-pod-name> -c secrets-store --since=1h | grep ^E
```

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

Примечание.

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

Причина 1. Не удалось получить маркер хранилища ключей

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

Предупреждение FailedMount 74s kubelet MountVolume.SetUp завершилось сбоем для тома "secret-store-inline": kubernetes.io/csi: mounter. Сбой setupAt: ошибка rpc: код = Неизвестно desc = не удалось подключить объекты хранилища секретов для pod default/test, err: ошибка rpc: code = Unknown desc = fail to mount objects, error: failed to get keyvault client: failed to get keyvault token: nmi responseed with status code: 404, err: <nil>

Эта ошибка возникает, так как компонент управляемого удостоверения узла (NMI) в удостоверении aad-pod вернул сообщение об ошибке о запросе маркера.

Решение 1. Проверка журналов pod NMI

Дополнительные сведения об этой ошибке и ее устранении, проверьте журналы pod NMI и ознакомьтесь с руководством по устранению неполадок с удостоверениями pod Microsoft Entra.

Причина 2. Объект pod поставщика не может получить доступ к экземпляру хранилища ключей

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

E1029 17:37:42.461313 1 server.go:54] не удалось обработать запрос на подключение, ошибку: keyvault. BaseClient#GetSecret: сбой отправки запроса: StatusCode=0 - Исходная ошибка: превышен срок контекста

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

правило брандмауэра блокирует исходящий трафик от поставщика;
сетевые политики кластера AKS блокируют исходящий трафик;
Модули pod поставщика выполняются в сети узла. Сбой может произойти, если политика блокирует этот трафик или если на узле возникают неполадки в сети.

Решение 2. Проверка политик сети, списка разрешений и подключения к узлу

Чтобы устранить проблему, выполните следующие действия.

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

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

Создайте pod.

cat <<EOF | kubectl apply --filename -
apiVersion: v1
kind: Pod
metadata:
  name: curl
spec:
  hostNetwork: true
  containers:
  - args:
    - tail
    - -f
    - /dev/null
    image: curlimages/curl:7.75.0
    name: curl
  dnsPolicy: ClusterFirst
  restartPolicy: Always
EOF

Запустите exec kubectl, чтобы выполнить команду в созданном модуле pod:
```
kubectl exec --stdin --tty  curl -- sh
```

Проверка подлинности с помощью хранилища ключей Azure:

curl -X POST 'https://login.microsoftonline.com/<aad-tenant-id>/oauth2/v2.0/token' \
     -d 'grant_type=client_credentials&client_id=<azure-client-id>&client_secret=<azure-client-secret>&scope=https://vault.azure.net/.default'

Попробуйте получить секрет, который уже создан в хранилище ключей Azure:

curl -X GET 'https://<key-vault-name>.vault.azure.net/secrets/<secret-name>?api-version=7.2' \
     -H "Authorization: Bearer <access-token-acquired-above>"

Причина 3. Неверное управляемое удостоверение, назначаемое пользователем, в пользовательском ресурсе SecretProviderClass

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

MountVolume.SetUp failed for volume "<volume-name>" :  
  rpc error:  
    code = Unknown desc = failed to mount secrets store objects for pod <namespace>/<pod>,  
    err: rpc error: code = Unknown desc = failed to mount objects,  
    error: failed to get objectType:secret, objectName:<key-vault-secret-name>, objectVersion:: azure.BearerAuthorizer#WithAuthorization:  
      Failed to refresh the Token for request to https://<key-vault-name>.vault.azure.net/secrets/<key-vault-secret-name>/?api-version=2016-10-01:  
        StatusCode=400 -- Original Error: adal: Refresh request failed.  
        Status Code = '400'.  
        Response body: {"error":"invalid_request","error_description":"Identity not found"}  
        Endpoint http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&client_id=<userAssignedIdentityID>&resource=https%!!(MISSING)A(MISSING)%!!(MISSING)F(MISSING)%!!(MISSING)F(MISSING)vault.azure.net

Решение 3. Обновление SecretProviderClass с помощью правильного значения userAssignedIdentityID

Найдите правильное управляемое удостоверение, назначаемое пользователем, а затем обновите SecretProviderClass пользовательский ресурс, чтобы указать правильное значение в параметре userAssignedIdentityID . Чтобы найти правильное управляемое удостоверение, назначаемое пользователем, выполните следующую команду az aks show в Azure CLI:

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

Сведения о настройке SecretProviderClass настраиваемого ресурса в формате YAML см. в разделе "Использование управляемого удостоверения, назначаемого пользователем" статьи "Предоставление удостоверения для доступа к поставщику Хранилища ключей Azure для хранилища секретов для драйвера CSI".

Причина 4. Частная конечная точка хранилища ключей находится в виртуальной сети, отличной от виртуальной сети узлов AKS

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

MountVolume.SetUp failed for volume "<volume>" :  
  rpc error:  
    code = Unknown desc = failed to mount secrets store objects for pod <namespace>/<pod>,  
    err: rpc error: code = Unknown desc = failed to mount objects,  
    error: failed to get objectType:secret, objectName: :<key-vault-secret-name>, objectVersion:: keyvault.BaseClient#GetSecret:  
      Failure responding to request:  
        StatusCode=403 -- Original Error: autorest/azure: Service returned an error.  
        Status=403 Code="Forbidden"  
        Message="Public network access is disabled and request is not from a trusted service nor via an approved private link.\r\n  
        Caller: appid=<application-id>;oid=<object-id>;iss=https://sts.windows.net/<id>/;xms_mirid=/subscriptions/<subscription-id>/resourcegroups/<aks-infrastructure-resource-group>/providers/Microsoft.Compute/virtualMachineScaleSets/aks-<nodepool-name>-<nodepool-id>-vmss;xms_az_rid=/subscriptions/<subscription-id>/resourcegroups/<aks-infrastructure-resource-group>/providers/Microsoft.Compute/virtualMachineScaleSets/aks-<nodepool-name>-<nodepool-id>-vmss \r\n  
        Vault: <keyvaultname>;location=<location>" InnerError={"code":"ForbiddenByConnection"}

Решение 4a. Настройка канала виртуальной сети и пиринга виртуальной сети для подключения виртуальных сетей

Устранение проблемы с подключением обычно представляет собой двухэтапный процесс:

Создайте ссылку виртуальной сети для виртуальной сети кластера AKS на уровне частной зоны Azure DNS.
Добавьте пиринг между виртуальной сетью кластера AKS и виртуальной сетью частной конечной точки Key Vault.

Данные шаги подробно описываются в следующих разделах.

Шаг 1. Создание ссылки виртуальной сети

Подключитесь к узлам кластера AKS, чтобы определить, разрешено ли полное доменное имя хранилища ключей через общедоступный IP-адрес или частный IP-адрес. Если вы получаете сообщение об ошибке "Доступ к общедоступной сети отключен и запрос не из доверенной службы, ни через утвержденную приватную ссылку" сообщение об ошибке, конечная точка Key Vault, вероятно, разрешается через общедоступный IP-адрес. Чтобы проверить этот сценарий, выполните команду nslookup :

nslookup <key-vault-name>.vault.azure.net

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

root@aks-<nodepool-name>-<nodepool-id>-vmss<scale-set-instance>:/# nslookup <key-vault-name>.vault.azure.net
Server:         168.63.129.16
Address:        168.63.129.16#53

Non-authoritative answer:
<key-vault-name>.vault.azure.net  canonical name = <key-vault-name>.privatelink.vaultcore.azure.net.
<key-vault-name>.privatelink.vaultcore.azure.net  canonical name = data-prod.weu.vaultcore.azure.net.
data-prod-weu.vaultcore.azure.net  canonical name = data-prod-weu-region.vaultcore.azure.net.
data-prod-weu-region.vaultcore.azure.net  canonical name = azkms-prod-weu-b.westeurope.cloudapp.azure.com.
Name:   azkms-prod-weu-b.westeurope.cloudapp.azure.com
Address: 20.1.2.3

В этом случае создайте ссылку виртуальной сети для виртуальной сети кластера AKS на уровне частной зоны DNS. (Ссылка виртуальной сети уже создана автоматически для виртуальной сети частной конечной точки Key Vault.)

Чтобы создать связь с виртуальную сеть, сделайте следующее:

В портал Azure найдите и выберите Частная зона DNS зоны.
В списке частных зон DNS выберите имя частной зоны DNS. В этом примере частная зона DNS privatelink.vaultcore.azure.net.
В области навигации частной зоны DNS найдите заголовок "Параметры" и выберите ссылки виртуальной сети.
В списке ссылок виртуальной сети нажмите кнопку "Добавить".

На странице "Добавление канала виртуальной сети" заполните следующие поля.

Имя поля	Действие
Имя ссылки	Введите имя, используемое для ссылки виртуальной сети.
Подписка	Выберите имя подписки, которую требуется содержать ссылку виртуальной сети.
Виртуальная сеть	Выберите имя виртуальной сети кластера AKS.

Выберите кнопку ОК.

После завершения процедуры создания ссылки выполните nslookup команду. Теперь выходные данные должны выглядеть примерно так, как показано более прямое разрешение DNS:

root@aks-<nodepool-name>-<nodepool-id>-vmss<scale-set-instance>:/# nslookup <key-vault-name>.vault.azure.net
Server:         168.63.129.16
Address:        168.63.129.16#53

Non-authoritative answer:
<key-vault-name>.vault.azure.net  canonical name = <key-vault-name>.privatelink.vaultcore.azure.net.
Name:   <key-vault-name>.privatelink.vaultcore.azure.net
Address: 172.20.0.4

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

Шаг 2. Добавление пиринга между виртуальными сетями

Если вы используете частную конечную точку, возможно, вы отключили общедоступный доступ на уровне Key Vault. Таким образом, между AKS и Key Vault не существует никакого подключения. Эту конфигурацию можно проверить с помощью следующей команды Netcat (nc):

nc -v -w 2 <key-vault-name>.vault.azure.net 443

Если подключение недоступно между AKS и Key Vault, вы увидите выходные данные, похожие на следующий текст:

nc: connect to <key-vault-name>.vault.azure.net port 443 (tcp) timed out: Operation now in progress

Чтобы установить подключение между AKS и Key Vault, добавьте пиринг между виртуальными сетями, выполнив следующие действия.

Переход на портал Azure.
Используйте один из следующих вариантов, чтобы выполнить инструкции из раздела "Создание однорангового узла виртуальной сети" руководства. Подключение виртуальных сетей с пирингом виртуальных сетей с помощью статьи портал Azure для пиринга виртуальных сетей и проверки подключения виртуальных сетей (с одного конца):
- Перейдите в виртуальную сеть AKS и выполните одноранговый пиринг в виртуальной сети частной конечной точки Key Vault.
- Перейдите в виртуальную сеть частной конечной точки Key Vault и выполните одноранговый пиринг в виртуальную сеть AKS.
В портал Azure найдите и выберите имя другой виртуальной сети (виртуальная сеть, к которую вы связали на предыдущем шаге).
В области навигации виртуальной сети найдите заголовок "Параметры", а затем выберите пиринги.
На странице пиринга виртуальной сети убедитесь, что столбец "Имя " содержит имя ссылки пиринга удаленной виртуальной сети , указанной на шаге 2. Кроме того, убедитесь, что столбец состояния пиринга для этой ссылки пиринга имеет значение Connected.

После выполнения этой процедуры можно снова запустить команду Netcat. Теперь разрешение DNS и подключение между AKS и Key Vault должны быть успешными. Кроме того, убедитесь, что секреты Key Vault успешно подключены и работают должным образом, как показано в следующих выходных данных:

Connection to <key-vault-name>.vault.azure.net 443 port [tcp/https] succeeded!

Решение 4b. Устранение неполадок с кодом ошибки 403

Устранение неполадок с кодом ошибки "403", просмотрев раздел HTTP 403: недостаточно разрешений в справочной статье по кодам ошибок REST API Azure Key Vault.

Причина 5. В списке зарегистрированных драйверов CSI отсутствует драйвер secrets-store.csi.k8s.io

Если вы получаете следующее сообщение об ошибке о отсутствующих secrets-store.csi.k8s.io драйверах в событиях pod, то модули pod CSI Для хранилища секретов не выполняются на узле, в котором выполняется приложение:

Предупреждение FailedMount 42s (x12 более 8m56s) kubelet, akswin000000 MountVolume.SetUp завершилось сбоем для тома "secret-store01-inline": kubernetes.io/csi: mounter. Не удалось получить клиент CSI SetUpAt: имя драйвера secrets-store.csi.k8s.io не найдено в списке зарегистрированных драйверов CSI

Решение 5. Устранение неполадок модуля pod драйвера CSI для хранилища секретов, запущенного на одном узле

Получите состояние модуля pod CSI Driver для хранилища секретов, запущенного на том же узле, выполнив следующую команду:

kubectl get pod -l app=secrets-store-csi-driver -n kube-system -o wide

Если состояние pod не Running является или какие-либо контейнеры в этом модуле pod не Ready заданы в состоянии, перейдите к журналам этого модуля, выполнив действия, описанные в разделе "Проверка журналов поставщика хранилища секретов и журналов pod драйвера CSI".

Причина 6. SecretProviderClass не найден

При описании модуля pod приложения может появиться следующее событие:

Events:
  Type     Reason       Age               From               Message
  ----     ------       ----              ----               -------
  Warning  FailedMount  2s (x5 over 10s)  kubelet            MountVolume.SetUp failed for volume "xxxxxxx" : rpc error: code = Unknown desc = failed to get secretproviderclass xxxxxxx/xxxxxxx, error: SecretProviderClass.secrets-store.csi.x-k8s.io "xxxxxxxxxxxxx" not found

Это событие указывает, что ссылка на спецификацию тома pod не существует в том же пространстве имен, что SecretProviderClass и модуль pod приложения.

Решение 6a. Создание отсутствующих ресурсов SecretProviderClass

Убедитесь, что SecretProviderClass ресурс, на который ссылается спецификация тома pod, существует в том же пространстве имен, где выполняется модуль pod приложения.

Решение 6b. Измените спецификацию тома pod приложения, чтобы ссылаться на правильное имя ресурса SecretProviderClass

Измените спецификацию тома pod приложения, чтобы ссылаться на правильное SecretProviderClass имя ресурса:

...
spec:
  containers:
  ...
  volumes:
    - name: my-volume
      csi:
        driver: secrets-store.csi.k8s.io
        readOnly: true
        volumeAttributes:
          secretProviderClass: "xxxxxxxxx"

Причина 7. Запрос не прошел проверку подлинности

Запрос не прошел проверку подлинности для Key Vault, как указано в коде ошибки "401".

Решение 7. Устранение неполадок с кодом ошибки 401

Устранение неполадок с кодом ошибки "401", просмотрев раздел "HTTP 401: запрос без проверки подлинности" справочной статьи по кодам ошибок REST API Azure Key Vault.

Причина 8. Число запросов превышает указанное максимальное значение.

Число запросов превышает указанное максимальное значение для интервала времени, как указано в коде ошибки "429".

Решение 8. Устранение неполадок с кодом ошибки 429

Устранение неполадок с кодом ошибки "429", просмотрев раздел "HTTP 429: слишком много запросов" справочной статьи по кодам ошибок REST API Azure Key Vault.

Заявление об отказе от ответственности за сведения о продуктах сторонних производителей

В этой статье упомянуты программные продукты независимых производителей. Корпорация Microsoft не дает никаких гарантий, подразумеваемых и прочих, относительно производительности и надежности этих продуктов.

Свяжитесь с нами для получения помощи

Если у вас есть вопросы или вам нужна помощь, создайте запрос в службу поддержки или обратитесь за поддержкой сообщества Azure. Вы также можете отправить отзыв о продукте в сообщество отзывов Azure.

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