Compartir a través de

Solución de problemas del proveedor de Azure Key Vault para el controlador CSI del Almacén de secretos

  • Artículo

En este artículo se describen los problemas comunes que puede experimentar al usar el controlador de la interfaz de almacenamiento de contenedor (CSI) del proveedor de microsoft Azure Key Vault para el almacén de secretos en Azure Kubernetes Service (AKS). En el artículo se proporcionan sugerencias de solución de problemas para resolver estos problemas.

Requisitos previos

Lista de comprobación para la solución de problemas

Los registros de Azure Key Vault están disponibles en los pods del proveedor y del controlador. Para solucionar problemas que afectan al proveedor o al controlador, examine los registros del pod del proveedor o del controlador que se ejecutan en el mismo nodo en el que se ejecuta el pod de aplicación.

Paso 1 de solución de problemas: Comprobación de los registros del proveedor del Almacén de secretos

Para buscar el secrets-store-provider-azure pod que se ejecuta en el mismo nodo en el que se ejecuta el pod de aplicación, ejecute los siguientes comandos kubectl get y kubectl logs que seleccionen la secrets-store-provider-azure aplicación:

kubectl get pods --selector 'app in (csi-secrets-store-provider-azure, secrets-store-provider-azure)' \
    --all-namespaces \
    --output wide
kubectl logs <provider-pod-name> --since=1h | grep ^E

Paso 2 de solución de problemas: Comprobación de los registros de controladores CSI del Almacén de secretos

Para acceder a los registros del controlador CSI del Almacén de secretos, ejecute los mismos comandos que en el paso 1, pero seleccione la secrets-store-csi-driver aplicación en su lugar y especifique el secrets-store contenedor:

kubectl get pods --selector app=secrets-store-csi-driver --all-namespaces --output wide
kubectl logs <driver-pod-name> --container secrets-store --since=1h | grep ^E

Nota:

Si abre una solicitud de soporte técnico, es una buena idea incluir los registros pertinentes del proveedor de Azure Key Vault y el controlador CSI del Almacén de secretos.

Causa 1: No se pudo recuperar el token del almacén de claves

Es posible que vea la siguiente entrada de error en los registros o mensajes de evento:

Advertencia FailedMount 74s kubelet MountVolume.SetUp failed for volume "secrets-store-inline" : kubernetes.io/csi: mounter. Error de SetupAt: error rpc: code = Unknown desc = failed to mount secrets store objects for pod default/test, err: rpc error: code = Unknown desc = failed to mount objects, error: failed to get keyvault client: failed to get key vault token: nmi response failed with status code: 404, err: <nil>

Este error se produce porque un componente de identidad administrada de nodo (NMI) en aad-pod-identity devolvió un mensaje de error sobre una solicitud de token.

Solución 1: Comprobación de los registros de pod de NMI

Para obtener más información sobre este error y cómo resolverlo, consulte los registros de pod de NMI y consulte la guía de solución de problemas de identidad de pod de Microsoft Entra.

Causa 2: El pod del proveedor no puede acceder a la instancia del almacén de claves

Es posible que vea la siguiente entrada de error en los registros o mensajes de evento:

E1029 17:37:42.461313 1 server.go:54] no pudo procesar la solicitud de montaje, error: keyvault. BaseClient#GetSecret: Error al enviar la solicitud: StatusCode=0 -- Error original: se ha superado la fecha límite del contexto

Este error se produce porque el pod del proveedor no puede acceder a la instancia del almacén de claves. Es posible que se impida el acceso por cualquiera de los siguientes motivos:

  • Una regla de firewall bloquea el tráfico de salida del proveedor.

  • Las directivas de red configuradas en el clúster de AKS bloquean el tráfico de salida.

  • Los pods del proveedor se ejecutan en la red host. Puede producirse un error si una directiva bloquea este tráfico o si se producen fluctuaciones de red en el nodo.

Solución 2: Comprobación de directivas de red, lista de permitidos y conexión de nodo

Para corregir el problema, realice las siguientes acciones:

  • Coloque los pods del proveedor en la lista de permitidos.

  • Compruebe si hay directivas configuradas para bloquear el tráfico.

  • Asegúrese de que el nodo tiene conectividad con Microsoft Entra ID y el almacén de claves.

Para probar la conectividad con el almacén de claves de Azure desde el pod que se ejecuta en la red host, siga estos pasos:

  1. Cree el 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

  2. Ejecute kubectl exec para ejecutar un comando en el pod que creó:

    kubectl exec --stdin --tty  curl -- sh

  3. Autentíquese mediante el almacén de claves de 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'

  4. Intente obtener un secreto que ya se ha creado en el almacén de claves de 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>"

Causa 3: La identidad administrada asignada por el usuario no es correcta en el recurso personalizado SecretProviderClass

Si encuentra una instancia de código de error HTTP "400" que va acompañada de una descripción de error "Identidad no encontrada", la identidad administrada asignada por el usuario no es correcta en el SecretProviderClass recurso personalizado. La respuesta completa es similar al texto siguiente:

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

Solución 3: Actualizar SecretProviderClass mediante el valor de userAssignedIdentityID correcto

Busque la identidad administrada asignada por el usuario correcta y, a continuación, actualice el SecretProviderClass recurso personalizado para especificar el valor correcto en el userAssignedIdentityID parámetro . Para encontrar la identidad administrada asignada por el usuario correcta, ejecute el siguiente comando az aks show en la CLI de Azure:

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

Para obtener información sobre cómo configurar un SecretProviderClass recurso personalizado en formato YAML, consulte la sección Uso de una identidad administrada asignada por el usuario del artículo Proporcionar una identidad para acceder al proveedor de Azure Key Vault para el controlador CSI del Almacén de secretos.

Causa 4: el punto de conexión privado Key Vault está en una red virtual diferente a los nodos de AKS

No se permite el acceso a la red pública en el nivel de Azure Key Vault y la conectividad entre AKS y Key Vault se realiza a través de un vínculo privado. Sin embargo, los nodos de AKS y el punto de conexión privado de la Key Vault se encuentran en redes virtuales diferentes. Este escenario genera un mensaje similar al texto siguiente:

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"}

La corrección del problema de conectividad suele ser un proceso de dos pasos:

Estos pasos se describen con más detalle en las secciones siguientes.

Conéctese a los nodos del clúster de AKS para determinar si el nombre de dominio completo (FQDN) de la Key Vault se resuelve a través de una dirección IP pública o una dirección IP privada. Si recibe el mensaje de error "El acceso a la red pública está deshabilitado y la solicitud no es de un servicio de confianza ni a través de un vínculo privado aprobado", es probable que el punto de conexión de Key Vault se resuelva a través de una dirección IP pública. Para comprobar este escenario, ejecute el comando nslookup :

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

Si el FQDN se resuelve a través de una dirección IP pública, la salida del comando es similar al texto siguiente:

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

En este caso, cree un vínculo de red virtual para la red virtual del clúster de AKS en el nivel de zona DNS privada. (Ya se ha creado automáticamente un vínculo de red virtual para la red virtual del punto de conexión privado de Key Vault).

Para crear el vínculo de red virtual, siga estos pasos:

  1. En el Azure Portal, busque y seleccione DNS privado zonas.

  2. En la lista de zonas DNS privadas, seleccione el nombre de la zona DNS privada. En este ejemplo, se privatelink.vaultcore.azure.net la zona DNS privada.

  3. En el panel de navegación de la zona DNS privada, busque el encabezado Configuración y, a continuación, seleccione Vínculos de red virtual.

  4. En la lista de vínculos de red virtual, seleccione Agregar.

  5. En la página Agregar vínculo de red virtual , complete los campos siguientes.

    Nombre del campo Acción
    Nombre del vínculo Escriba un nombre que se usará para el vínculo de red virtual.
    Subscription Seleccione el nombre de la suscripción que desea que contenga el vínculo de red virtual.
    Red virtual Seleccione el nombre de la red virtual del clúster de AKS.

  6. Seleccione el botón Aceptar.

Después de finalizar el procedimiento de creación de vínculos, ejecute el nslookup comando . La salida ahora debe ser similar al texto siguiente que muestra una resolución DNS más directa:

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

Una vez agregado el vínculo de red virtual, el FQDN debe resolverse a través de una dirección IP privada.

Paso 2: Agregar emparejamiento de red virtual entre redes virtuales

Si usa un punto de conexión privado, probablemente haya deshabilitado el acceso público en el nivel de Key Vault. Por lo tanto, no existe conectividad entre AKS y el Key Vault. Puede probar esa configuración mediante el siguiente comando de Netcat (nc):

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

Si la conectividad no está disponible entre AKS y el Key Vault, verá una salida similar al texto siguiente:

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

Para establecer la conectividad entre AKS y el Key Vault, agregue el emparejamiento de red virtual entre las redes virtuales siguiendo estos pasos:

  1. Vaya a Azure Portal.

  2. Use una de las siguientes opciones para seguir las instrucciones de la sección Crear red virtual del mismo nivel del Tutorial: Conexión de redes virtuales con emparejamiento de redes virtuales mediante el artículo Azure Portal para emparejar las redes virtuales y comprobar que las redes virtuales están conectadas (desde un extremo):

    • Vaya a la red virtual de AKS y emparejarla con la red virtual del punto de conexión privado de Key Vault.

    • Vaya a la red virtual del punto de conexión privado de Key Vault y emparejarlo con la red virtual de AKS.

  3. En el Azure Portal, busque y seleccione el nombre de la otra red virtual (la red virtual a la que emparejaba en el paso anterior).

  4. En el panel de navegación de la red virtual, busque el encabezado Configuración y seleccione Emparejamientos.

  5. En la página emparejamiento de red virtual, compruebe que la columna Nombre contiene el nombre del vínculo de emparejamiento de la red virtual remota que especificó en el paso 2. Además, asegúrese de que la columna Estado de emparejamiento de ese vínculo de emparejamiento tenga un valor de Conectado.

Después de completar este procedimiento, puede volver a ejecutar el comando de Netcat. La resolución dns y la conectividad entre AKS y el Key Vault ahora deben realizarse correctamente. Además, asegúrese de que los secretos de Key Vault se montan correctamente y funcionan según lo previsto, como se muestra en la salida siguiente:

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

Solución 4b: Solución de problemas de código de error 403

Para solucionar problemas del código de error "403", revise la sección HTTP 403: Permisos insuficientes del artículo Referencia de códigos de error de la API REST de Azure Key Vault.

Causa 5: Falta el controlador secrets-store.csi.k8s.io de la lista de controladores CSI registrados

Si recibe el siguiente mensaje de error sobre un controlador que falta secrets-store.csi.k8s.io en los eventos de pod, los pods del controlador CSI del Almacén de secretos no se ejecutan en el nodo en el que se ejecuta la aplicación:

Advertencia FailedMount 42s (x12 over 8m56s) kubelet, akswin000000 MountVolume.SetUp failed for volume "secrets-store01-inline" : kubernetes.io/csi: mounter. SetUpAt no pudo obtener el cliente CSI: el nombre del controlador no secrets-store.csi.k8s.io encuentra en la lista de controladores CSI registrados

Solución 5a: Instalar el controlador CSI del almacén de secretos

Si instaló el proveedor de Key Vault mediante manifiestos de implementación, siga las instrucciones para instalar el controlador CSI del Almacén de secretos.

Solución 5b: vuelva a implementar el controlador CSI del almacén de secretos y el proveedor de Key Vault agregando tolerancia de taint

Si ya ha implementado el controlador CSI del Almacén de secretos, compruebe si el nodo está manchado. Si el nodo está manchado, vuelva a implementar el controlador CSI del almacén de secretos y Key Vault proveedor agregando tolerancia para los taints.

Solución 5c: (solo Windows) Use los valores de configuración de Helm al instalar el controlador CSI del Almacén de secretos y el proveedor de Key Vault

Si la aplicación se ejecuta en un nodo de Windows, instale el controlador CSI de la Tienda de secretos y el proveedor de Key Vault en los nodos de Windows mediante los valores de configuración de Helm.

Causa 6: El controlador no puede comunicarse con el proveedor

Si recibe el siguiente mensaje de error en los registros o eventos, el controlador no puede comunicarse con el proveedor:

Advertencia FailedMount 85s (x10 over 5m35s) kubelet, aks-default-28951543-vmss000000 MountVolume.SetUp failed for volume "secrets-store01-inline" : kubernetes.io/csi: mounter. Error de SetupAt: rpc error: code = Unknown desc = failed to mount secrets store objects for pod default/nginx-secrets-store-inline-user-msi, err: failed to find provider binary azure, err: stat /etc/kubernetes/secrets-store-csi-providers/azure/provider-azure: no such file or directory

Solución 6a: (Versiones del proveedor anteriores a la versión 0.0.9) Asegúrese de que los pods del proveedor se ejecuten en todos los nodos.

Si la versión instalada del proveedor de Key Vault es anterior a la versión 0.0.9, asegúrese de que los pods del proveedor se ejecutan en todos los nodos.

Solución 6b: (provider version 0.0.9 y versiones posteriores) Use gRPC para la comunicación del proveedor.

Si instaló Key Vault versión 0.0.9 del proveedor o una versión posterior, configure el controlador para que se comunique con el proveedor mediante gRPC.

Causa 7: El controlador CSI no puede crear el secreto de Kubernetes

Si recibe el siguiente mensaje de error en el contenedor secret-store en el controlador CSI, no ha instalado el rol de clúster de control de acceso basado en rol (RBAC) ni el enlace de roles de clúster. El rol de clúster y el enlace de roles de clúster son necesarios para que el controlador CSI sincronice el contenido montado como secreto de Kubernetes.

E0610 22:27:02.283100 1 secretproviderclasspodstatus_controller.go:325] "failed to create Kubernetes secret" err="secrets is forbidden: User \"system:serviceaccount:default:secrets-store-csi-driver\" cannot create resource \"secrets\" in API group \"\" in el espacio de nombres \"default\"" spc="default/azure-linux" pod="default/busybox-linux-5f479855f7-jvfw4" secret="default/dockerconfig" spcps="default/busybox-linux-5f479855f7-jvfw4-default-azure-linux"

Solución 7: Instalación del rol de clúster y el enlace de roles de clúster necesarios

Al instalar o actualizar el controlador CSI y el proveedor de Key Vault mediante gráficos de Helm desde el repositorio secrets-store-csi-driver-provider-azure GitHub, establezca el secrets-store-csi-driver.syncSecret.enabled parámetro helm en true. Este cambio de configuración instala el rol de clúster y el enlace de roles de clúster necesarios.

Para comprobar que el rol de clúster y el enlace de roles de clúster están instalados, ejecute los comandos siguientes kubectl get :

# Synchronize as Kubernetes secret cluster role.
kubectl get clusterrole/secretprovidersyncing-role

# Synchronize as Kubernetes secret cluster role binding.
kubectl get clusterrolebinding/secretprovidersyncing-rolebinding

Causa 8: La solicitud no está autenticada

La solicitud no está autenticada para Key Vault, como se indica en un código de error "401".

Solución 8: Solución de problemas del código de error 401

Para solucionar problemas del código de error "401", revise la sección "HTTP 401: Solicitud no autenticada" del artículo Referencia de códigos de error de la API REST de Azure Key Vault.

Causa 9: El número de solicitudes supera el máximo indicado

El número de solicitudes supera el máximo indicado para el período de tiempo, como se indica en un código de error "429".

Solución 9: Solución de problemas del código de error 429

Para solucionar problemas del código de error "429", revise la sección "HTTP 429: Demasiadas solicitudes" del artículo Referencia de códigos de error de la API REST de Azure Key Vault.

Aviso de declinación de responsabilidades sobre la información de terceros

Los productos de otros fabricantes que se mencionan en este artículo han sido creados por compañías independientes de Microsoft. Microsoft no ofrece ninguna garantía, ya sea implícita o de otro tipo, sobre la confiabilidad o el rendimiento de dichos productos.

Ponte en contacto con nosotros para obtener ayuda

Si tiene preguntas o necesita ayuda, cree una solicitud de soporte o busque consejo en la comunidad de Azure. También puede enviar comentarios sobre el producto con los comentarios de la comunidad de Azure.