Partilhar via

Solucionar problemas do Provedor de Key Vault do Azure para Driver CSI da Loja de Segredos

  • Artigo

Este artigo discute problemas comuns que você pode enfrentar ao usar o Driver CSI (Provedor de Key Vault do Microsoft Azure para Interface de Armazenamento de Contêineres) da Repositório de Segredos (CSI) em Serviço de Kubernetes do Azure (AKS). O artigo fornece dicas de solução de problemas para resolver esses problemas.

Pré-requisitos

Lista de verificação de solução de problemas

Os logs de Key Vault do Azure estão disponíveis nos pods de provedor e driver. Para solucionar problemas que afetam o provedor ou o driver, examine os logs do provedor ou do pod de driver em execução no mesmo nó em que o pod de aplicativo é executado.

Solução de problemas etapa 1: verificar os logs do provedor da Repositório de Segredos

Para localizar o secrets-store-provider-azure pod executado no mesmo nó em que o pod de aplicativo é executado, execute os seguintes comandos de logs kubectl get e kubectl que selecionam o secrets-store-provider-azure aplicativo:

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

Solução de problemas etapa 2: verificar os logs de driver csi da Loja de Segredos

Para acessar os logs do Driver CSI da Loja de Segredos, execute os mesmos comandos da Etapa 1, mas selecione o secrets-store-csi-driver aplicativo e especifique o secrets-store contêiner:

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

Observação

Se você abrir uma solicitação de suporte, é uma boa ideia incluir os logs relevantes do provedor de Key Vault do Azure e do Driver CSI da Loja de Segredos.

Causa 1: não foi possível recuperar o token do cofre de chaves

Você pode ver a seguinte entrada de erro nos logs ou mensagens de evento:

Falha no kubelet MountVolume.SetUp do FailedMount 74s com falha no volume "secrets-store-inline" : kubernetes.io/csi: mounter. SetupAt falhou: erro rpc: code = desc desconhecido = falha ao montar objetos de armazenamento de segredos para o pod padrão/teste, err: erro rpc: code = desconhecido desc = falha ao montar objetos, erro: falha ao obter o cliente keyvault: falha ao obter o token do cofre de chaves: falha na resposta nmi com status código: 404, err: <zero>

Esse erro ocorre porque um componente NMI (Identidade Gerenciada de Nó) no aad-pod-identity retornou uma mensagem de erro sobre uma solicitação de token.

Solução 1: verificar os logs de pod NMI

Para obter mais informações sobre esse erro e como resolve-lo, marcar os logs de pod NMI e consulte o guia de solução de problemas de identidade do pod Microsoft Entra.

Causa 2: o pod do provedor não pode acessar a instância do cofre de chaves

Você pode ver a seguinte entrada de erro nos logs ou mensagens de evento:

O E1029 17:37:42.461313 1 server.go:54] falhou ao processar a solicitação de montagem, erro: keyvault. BaseClient#GetSecret: Solicitação de envio de falhas: StatusCode=0 -- Erro original: prazo de contexto excedido

Esse erro ocorre porque o pod do provedor não pode acessar a instância do cofre de chaves. O acesso pode ser impedido por qualquer um dos seguintes motivos:

  • Uma regra de firewall está bloqueando o tráfego de saída do provedor.

  • As políticas de rede configuradas no cluster do AKS estão bloqueando o tráfego de saída.

  • Os pods do provedor são executados na rede de host. Uma falha poderá ocorrer se uma política estiver bloqueando esse tráfego ou se ocorrer um nervosismo de rede no nó.

Solução 2: verificar políticas de rede, lista de permissões e conexão de nó

Para corrigir o problema, execute as seguintes ações:

  • Coloque os pods do provedor na lista de permissões.

  • Verifique se há políticas configuradas para bloquear o tráfego.

  • Verifique se o nó tem conectividade com Microsoft Entra ID e seu cofre de chaves.

Para testar a conectividade com o cofre de chaves do Azure no pod que está em execução na rede de host, siga estas etapas:

  1. Criar o 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. Execute o kubectl exec para executar um comando no pod que você criou:

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

  3. Autenticar usando o cofre de chaves do 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. Tente obter um segredo que já foi criado no cofre de chaves do 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: A identidade gerenciada atribuída pelo usuário está incorreta no recurso personalizado SecretProviderClass

Se você encontrar uma instância de erro HTTP "400" acompanhada de uma descrição de erro "Identidade não encontrada", a identidade gerenciada atribuída pelo usuário estará incorreta em seu SecretProviderClass recurso personalizado. A resposta completa se assemelha ao seguinte texto:

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

Solução 3: Atualizar SecretProviderClass usando o valor userAssignedIdentityID correto

Encontre a identidade gerenciada atribuída pelo usuário correta e atualize o SecretProviderClass recurso personalizado para especificar o valor correto no userAssignedIdentityID parâmetro. Para localizar a identidade gerenciada atribuída pelo usuário correto, execute o seguinte comando az aks show na CLI do Azure:

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

Para obter informações sobre como configurar um SecretProviderClass recurso personalizado no formato YAML, consulte a seção Usar uma identidade gerenciada atribuída pelo usuário do Fornecer uma identidade para acessar o artigo Driver CSI do Provedor de Key Vault do Azure para Repositório de Segredos.

Causa 4: o ponto de extremidade privado Key Vault está em uma rede virtual diferente dos nós do AKS

O acesso à rede pública não é permitido no nível Key Vault do Azure e a conectividade entre AKS e Key Vault é feita por meio de um link privado. No entanto, os nós do AKS e o ponto de extremidade privado do Key Vault estão em redes virtuais diferentes. Esse cenário gera uma mensagem que se assemelha ao seguinte texto:

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

Corrigir o problema de conectividade geralmente é um processo de duas etapas:

Essas etapas são descritas com mais detalhes nas seções a seguir.

Conecte-se aos nós de cluster do AKS para determinar se o FQDN (nome de domínio totalmente qualificado) do Key Vault é resolvido por meio de um endereço IP público ou um endereço IP privado. Se você receber a mensagem de erro "O acesso à rede pública está desabilitado e a solicitação não é de um serviço confiável nem por meio de um link privado aprovado", o ponto de extremidade Key Vault provavelmente será resolvido por meio de um endereço IP público. Para marcar para esse cenário, execute o comando nslookup:

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

Se o FQDN for resolvido por meio de um endereço IP público, a saída de comando se assemelha ao seguinte texto:

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

Nesse caso, crie um link de rede virtual para a rede virtual do cluster AKS no nível da zona DNS privada. (Um link de rede virtual já é criado automaticamente para a rede virtual do Key Vault ponto de extremidade privado.)

Para criar o link de rede virtual, siga estas etapas:

  1. No portal do Azure, pesquise e selecione DNS privado zonas.

  2. Na lista de zonas DNS privadas, selecione o nome da zona DNS privada. Neste exemplo, a zona DNS privada é privatelink.vaultcore.azure.net.

  3. No painel de navegação da zona DNS privada, localize o título Configurações e selecione Links de rede virtual.

  4. Na lista de links de rede virtual, selecione Adicionar.

  5. Na página Adicionar link de rede virtual , conclua os campos a seguir.

    Nome do campo Ação
    Nome do link Insira um nome a ser usado para o link de rede virtual.
    Assinatura Selecione o nome da assinatura que você deseja conter o link de rede virtual.
    Rede virtual Selecione o nome da rede virtual do cluster do AKS.

  6. Selecione o botão OK.

Depois de concluir o procedimento de criação de link, execute o nslookup comando. A saída agora deve se assemelhar ao seguinte texto que mostra uma resolução DNS mais direta:

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

Depois que o link de rede virtual for adicionado, o FQDN deverá ser resolvido por meio de um endereço IP privado.

Etapa 2: Adicionar emparelhamento de rede virtual entre redes virtuais

Se você estiver usando um ponto de extremidade privado, provavelmente desabilitou o acesso público no nível Key Vault. Portanto, não existe conectividade entre o AKS e o Key Vault. Você pode testar essa configuração usando o seguinte comando Netcat (nc):

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

Se a conectividade não estiver disponível entre o AKS e o Key Vault, você verá uma saída que se assemelha ao seguinte texto:

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

Para estabelecer a conectividade entre o AKS e o Key Vault, adicione o emparelhamento de rede virtual entre as redes virtuais seguindo estas etapas:

  1. Acesse o Portal do Azure.

  2. Use uma das seguintes opções para seguir as instruções da seção Criar par de rede virtual do Tutorial: conectar redes virtuais com emparelhamento de rede virtual usando o artigo portal do Azure para emparelhar as redes virtuais e verificar se as redes virtuais estão conectadas (de uma extremidade):

    • Vá para sua rede virtual do AKS e emparelhe-a para a rede virtual do ponto de extremidade privado Key Vault.

    • Vá para a rede virtual do Key Vault ponto de extremidade privado e emparelhe-a para a rede virtual AKS.

  3. No portal do Azure, pesquise e selecione o nome da outra rede virtual (a rede virtual que você emparelhou na etapa anterior).

  4. No painel de navegação de rede virtual, localize o título Configurações e selecione Emparelhamentos.

  5. Na página emparelhamento de rede virtual, verifique se a coluna Name contém o nome do link Emparelhamento da rede virtual remota especificada na etapa 2. Além disso, verifique se a coluna Emparelhamento status para esse link de emparelhamento tem um valor de Conectado.

Depois de concluir esse procedimento, você poderá executar o comando Netcat novamente. A resolução DNS e a conectividade entre o AKS e o Key Vault agora devem ter êxito. Além disso, certifique-se de que os segredos Key Vault sejam montados com êxito e funcionem conforme o esperado, conforme mostrado pela seguinte saída:

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

Solução 4b: solucionar problemas do código de erro 403

Solucionar problemas do código de erro "403" examinando a seção HTTP 403: Permissões insuficientes do artigo de referência de Códigos de Erro da API REST Key Vault Azure.

Causa 5: O driver secrets-store.csi.k8s.io está ausente da lista de drivers CSI registrados

Se você receber a seguinte mensagem de erro sobre um driver ausente secrets-store.csi.k8s.io nos eventos do pod, os pods do Driver CSI da Loja de Segredos não serão executados no nó em que o aplicativo está em execução:

O kubelet FailedMount 42s (x12 over 8m56s), akswin00000 MountVolume.SetUp falhou no volume "secrets-store01-inline" : kubernetes.io/csi: mounter. SetUpAt não conseguiu obter o cliente CSI: o nome do driver não secrets-store.csi.k8s.io encontrado na lista de drivers CSI registrados

Solução 5a: instalar o Driver CSI da Loja de Segredos

Se você instalou o provedor Key Vault usando manifestos de implantação, siga as instruções para instalar o Driver CSI da Loja de Segredos.

Solução 5b: reimplantar o driver CSI da Loja de Segredos e o provedor de Key Vault adicionando tolerância de contaminação

Se você já implantou o Driver CSI da Loja de Segredos, marcar se o nó está contaminado. Se o nó estiver contaminado, reimplante o Driver CSI da Loja de Segredos e Key Vault provedor adicionando tolerância para as manchas.

Solução 5c: (somente Windows) Use valores de configuração do Helm ao instalar o driver CSI da Loja de Segredos e o provedor de Key Vault

Se o aplicativo estiver em execução em um nó do Windows, instale o Driver CSI da Loja de Segredos e Key Vault provedor em nós do Windows usando os valores de configuração do Helm.

Causa 6: o driver não pode se comunicar com o provedor

Se você receber a seguinte mensagem de erro nos logs ou eventos, o driver não poderá se comunicar com o provedor:

O kubelet FailedMount 85s (x10 mais de 5m35s), aks-default-28951543-vmss00000 MountVolume.SetUp falhou no volume "secrets-store01-inline" : kubernetes.io/csi: mounter. SetupAt falhou: erro rpc: code = desc desconhecido = falha ao montar objetos de armazenamento de segredos para o pod default/nginx-secrets-store-inline-user-msi, err: falha ao encontrar o provedor binário azure, err: stat /etc/kubernetes/secrets-store-csi-providers/azure/provider-azure: nenhum arquivo ou diretório desse tipo

Solução 6a: (Versões do provedor anteriores à versão 0.0.9) Verifique se os pods do provedor são executados em todos os nós

Se a versão do provedor Key Vault instalada for anterior à versão 0.0.9, verifique se os pods do provedor estão em execução em todos os nós.

Solução 6b: (Versão do provedor 0.0.9 e posterior) Use gRPC para comunicação do provedor

Se você instalou Key Vault provedor versão 0.0.9 ou posterior, configure o driver para se comunicar com o provedor usando gRPC.

Causa 7: o driver CSI não pode criar o segredo do Kubernetes

Se você receber a seguinte mensagem de erro no contêiner do repositório secreto no driver CSI, não instalou a função de cluster e a associação de função de cluster do RBAC (controle de acesso baseado em função). A função de cluster e a associação de função de cluster são necessárias para que o driver CSI sincronize o conteúdo montado como um segredo do Kubernetes.

E0610 22:27:02.283100 1 secretproviderclasspodstatus_controller.go:325] "falha ao criar segredo do Kubernetes" err="segredos são proibidos: usuário \"system:serviceaccount:default:secrets-store-csi-driver\" não pode criar recurso \"secrets\" no grupo de API \"\" no namespace \"default\"" spc="default/azure-linux" pod="default/busybox-linux-5f479855f7-jvfw4" secret="default/dockerconfig" spcps="default/busybox-linux-5f479855f7-jvfw4-default-azure-linux"

Solução 7: instalar a função de cluster necessária e a associação de função de cluster

Ao instalar ou atualizar o driver CSI e o provedor de Key Vault usando gráficos helm do repositório secrets-store-csi-driver-provider-azure GitHub, defina o secrets-store-csi-driver.syncSecret.enabled parâmetro Helm como true. Essa alteração de configuração instala a função de cluster necessária e a associação de função de cluster.

Para verificar se a função de cluster e a associação de função de cluster estão instaladas, execute os seguintes kubectl get comandos:

# 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: A solicitação não está autenticada

A solicitação não é autenticada para Key Vault, conforme indicado por um código de erro "401".

Solução 8: solucionar problemas do código de erro 401

Solucionar problemas do código de erro "401" examinando a seção "HTTP 401: Solicitação Não Autenticada" do artigo de referência de Códigos de Erro da API REST Key Vault Azure.

Causa 9: o número de solicitações excede o máximo declarado

O número de solicitações excede o máximo declarado para o período, conforme indicado por um código de erro "429".

Solução 9: solucionar problemas do código de erro 429

Solucionar problemas do código de erro "429" revisando a seção "HTTP 429: Solicitações Demais" do artigo de referência de Códigos de Erro da API REST Key Vault Azure.

Aviso de isenção de responsabilidade para informações de terceiros

Os produtos de terceiros mencionados neste artigo são produzidos por empresas independentes da Microsoft. A Microsoft não oferece nenhuma garantia, implícita ou não, do desempenho ou da confiabilidade desses produtos.

Entre em contato conosco para obter ajuda

Se você tiver dúvidas ou precisar de ajuda, crie uma solicitação de suporte ou peça ajuda à comunidade de suporte do Azure. Você também pode enviar comentários sobre o produto para a comunidade de comentários do Azure.