Solución de problemas del complemento del proveedor de secretos de Azure Key Vault en AKS

Artículo
12/13/2024

En este artículo se describe cómo solucionar problemas que puede experimentar al usar el complemento Proveedor de secretos de Azure Key Vault en Azure Kubernetes Service (AKS).

Nota:

Este artículo se aplica a la versión del complemento administrado de AKS del proveedor de secretos de Azure Key Vault. Si usa la versión de Helm instalada (autoadministrada), vaya a la documentación de GitHub del proveedor de Azure Key Vault para el controlador CSI del almacén de secretos.

Requisitos previos

CLI de Azure
La herramienta kubectl de Kubernetes (para instalar kubectl mediante la CLI de Azure, ejecute el comando az aks install-cli).
Complemento del controlador CSI del almacén de secretos de Kubernetes habilitado en el clúster de AKS
Herramienta url de cliente (curl)
La herramienta de línea de comandos Netcat (nc) para conexiones TCP

Lista de comprobación de solución de problemas

Paso 1: Confirmación de que el complemento proveedor de secretos de Azure Key Vault está habilitado en el clúster

Ejecute el comando az aks show para confirmar que el complemento está habilitado en el clúster:

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

La salida del comando debe ser similar al texto siguiente:

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

Si la enabled marca se muestra como false en la salida anterior, el complemento Proveedor de secretos de Azure Key Vault no está habilitado en el clúster. En este caso, consulte la documentación de GitHub del proveedor de Azure Key Vault para el controlador CSI del almacén de secretos para más solución de problemas.

Si la enabled marca se muestra como true en la salida anterior, el complemento Proveedor de secretos de Azure Key Vault está habilitado en el clúster. En este caso, vaya a los pasos siguientes de este artículo.

Paso 2: Comprobación de los registros del pod del proveedor del almacén de secretos y del controlador CSI

Los registros de complementos del proveedor de secretos de Azure Key Vault se generan mediante pods de proveedor y controlador. Para solucionar problemas que afectan al proveedor o controlador, examine los registros del pod que se ejecuta en el mismo nodo que el pod de la aplicación.

Ejecute el comando kubectl get para buscar los pods del proveedor del almacén de secretos y del controlador CSI que se ejecutan en el mismo nodo en el que se ejecuta el pod de la aplicación:
```
kubectl get pod -l 'app in (secrets-store-provider-azure, secrets-store-csi-driver)' -n kube-system -o wide
```
Ejecute el comando kubectl logs para ver los registros del pod del proveedor del almacén de secretos:
```
kubectl logs -n kube-system <provider-pod-name> --since=1h | grep ^E
```
Ejecute el comando kubectl logs para ver los registros desde el pod del controlador CSI del almacén de secretos:
```
kubectl logs -n kube-system <csi-driver-pod-name> -c secrets-store --since=1h | grep ^E
```

Una vez que recopile los registros del pod del proveedor del almacén de secretos y del controlador CSI, analice estos registros con las causas mencionadas en las secciones siguientes para identificar el problema y la solución correspondiente.

Nota:

Si abre una solicitud de soporte técnico, es recomendable 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. SetupAt failed: rpc error: 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: <nil>

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

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

Para obtener más información sobre este error y cómo resolverlo, compruebe los registros del pod de NMI y consulte la guía de solución de problemas de identidades 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 superó la fecha límite de contexto

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

Hay una regla de firewall que 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. Es posible que se produzca un error si una directiva bloquea este tráfico o si se producen vibración 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 el identificador de Microsoft Entra 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:

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

Ejecute kubectl exec para ejecutar un comando en el pod que creó:
```
kubectl exec --stdin --tty  curl -- sh
```

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'

Intente obtener un secreto que ya se haya 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 es incorrecta en el recurso personalizado SecretProviderClass

Si encuentra un código de error HTTP "400" que va acompañado de una descripción del error "Identidad no encontrada", la identidad administrada asignada por el usuario es incorrecta en SecretProviderClass el 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 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 buscar 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 de Key Vault está en una red virtual diferente a la de 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 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"}

Solución 4a: Configuración de un vínculo de red virtual y emparejamiento de red virtual para conectar las redes virtuales

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

Cree un vínculo de red virtual para la red virtual del clúster de AKS en el nivel de zona de Azure DNS privado.
Agregue el emparejamiento de red virtual entre la red virtual del clúster de AKS y la red virtual del punto de conexión privado de Key Vault.

En las secciones siguientes se describen estos pasos de forma más detallada.

Paso 1: Creación del vínculo de red virtual

Conéctese a los nodos del clúster de AKS para determinar si el nombre de dominio completo (FQDN) del almacén de claves 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 procede 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:

En Azure Portal, busque y seleccione DNS privado zonas.
En la lista de zonas DNS privadas, seleccione el nombre de la zona DNS privada. En este ejemplo, la zona DNS privada es privatelink.vaultcore.azure.net.
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.
En la lista de vínculos de red virtual, seleccione Agregar.

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.
Suscripción	Seleccione el nombre de la suscripción que desea contener el vínculo de red virtual.
Red virtual	Seleccione el nombre de la red virtual del clúster de AKS.

Selecciona el botón Aceptar.

Después de finalizar el procedimiento de creación de vínculos, ejecute el nslookup comando . La salida debería parecerse ahora 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: Adición del emparejamiento de redes virtuales 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 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 Key Vault, verá la 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 Key Vault, agregue el emparejamiento de red virtual entre las redes virtuales siguiendo estos pasos:

Vaya a Azure Portal.
Use una de las siguientes opciones para seguir las instrucciones de la sección Creación de redes virtuales del mismo nivel del tutorial: Conexión de redes virtuales con emparejamiento de redes virtuales mediante 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 conéctela a 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 conéctelo a la red virtual de AKS.
En Azure Portal, busque y seleccione el nombre de la otra red virtual (la red virtual a la que se empareja en el paso anterior).
En el panel de navegación de la red virtual, busque el encabezado Configuración y seleccione Emparejamientos.
En la página de emparejamiento de red virtual, compruebe que la columna Nombre contiene el nombre del vínculo Emparejamiento de la red virtual remota que especificó en el paso 2. Además, asegúrese de que la columna Estado de emparejamiento para ese vínculo de emparejamiento tiene un valor de Conectado.

Después de completar este procedimiento, puede volver a ejecutar el comando Netcat. La resolución DNS y la conectividad entre AKS y 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 del código de error 403

Solucione el código de error "403" revisando la sección HTTP 403: Permisos insuficientes del artículo de referencia 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 secrets-store.csi.k8s.io no se encontró en la lista de controladores CSI registrados.

Solución 5: Solución de problemas del pod del controlador CSI del almacén secreto que se ejecuta en el mismo nodo

Para recuperar el estado del pod del controlador CSI del almacén secreto que se ejecuta en el mismo nodo, ejecute el comando siguiente:

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

Si el estado del pod no Running es o ninguno de los contenedores de este pod no está en Ready estado, continúe con la comprobación de los registros de este pod siguiendo los pasos descritos en Comprobación del proveedor del almacén de secretos y los registros del pod del controlador CSI.

Causa 6: SecretProviderClass no encontrado

Es posible que vea el siguiente evento al describir el pod de la aplicación:

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

Este evento indica que la SecretProviderClass especificación de volumen del pod a la que se hace referencia no existe en el mismo espacio de nombres que el pod de la aplicación.

Solución 6a: Creación del recurso SecretProviderClass que falta

Asegúrese de que el recurso al que se hace referencia en la SecretProviderClass especificación de volumen del pod existe en el mismo espacio de nombres en el que se ejecuta el pod de la aplicación.

Solución 6b: modifique la especificación de volumen del pod de la aplicación para hacer referencia al nombre de recurso SecretProviderClass correcto.

Edite la especificación de volumen del pod de la aplicación para hacer referencia al nombre de recurso correcto SecretProviderClass :

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

Causa 7: 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 7: Solución de problemas del código de error 401

Solucione el código de error "401" revisando la sección "HTTP 401: Solicitud no autenticada" del artículo de referencia códigos de error de la API REST de Azure Key Vault.

Causa 8: 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 8: Solución de problemas del código de error 429

Solucione el código de error "429" revisando la sección "HTTP 429: Demasiadas solicitudes" del artículo de referencia 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.

Compartir a través de