Solucionar problemas do complemento do Provedor de Segredos do Azure Key Vault no AKS

Artigo
12/13/2024

Este artigo discute como solucionar problemas que você pode enfrentar ao usar o complemento Provedor de Segredos do Azure Key Vault no AKS (Serviço de Kubernetes do Azure).

Observação

Este artigo se aplica à versão de complemento gerenciado do AKS do Provedor de Segredos do Azure Key Vault. Se você usar a versão instalada (autogerenciada) do helm, acesse a documentação GitHub do Provedor do Azure Key Vault para o Driver CSI do Repositório de Segredos .

Pré-requisitos

CLI do Azure
A ferramenta kubectl do Kubernetes (Para instalar o kubectl usando a CLI do Azure, execute o comando az aks install-cli.)
O complemento do Driver CSI do Repositório de Segredos do Kubernetes, habilitado no cluster do AKS
A ferramenta de URL do cliente (curl)
A ferramenta de linha de comando Netcat (nc) para conexões TCP

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

Etapa 1: Confirmar se o complemento do Provedor de Segredos do Azure Key Vault está habilitado no cluster

Execute o comando az aks show para confirmar se o complemento está habilitado no cluster:

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

A saída do comando deve ser semelhante ao seguinte texto:

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

Se o enabled sinalizador for mostrado como false na saída anterior, o complemento Provedor de Segredos do Azure Key Vault não estará habilitado no cluster. Nesse caso, consulte a documentação do GitHub do Provedor do Azure Key Vault para o Driver CSI do Repositório de Segredos para obter mais soluções de problemas.

Se o enabled sinalizador for mostrado como true na saída anterior, o complemento Provedor de Segredos do Azure Key Vault será habilitado no cluster. Nesse caso, vá para as próximas etapas deste artigo.

Etapa 2: Verificar os logs do pod do provedor de repositório de segredos e do driver CSI

Os logs de complemento do Provedor de Segredos do Azure Key Vault são gerados por pods de provedor e driver. Para solucionar problemas que afetam o provedor ou o driver, examine os logs do pod que está sendo executado no mesmo nó que o pod do aplicativo.

Execute o comando kubectl get para localizar os pods do Provedor de Repositório de Segredos e do Driver CSI que são executados no mesmo nó em que o pod do aplicativo é executado:
```
kubectl get pod -l 'app in (secrets-store-provider-azure, secrets-store-csi-driver)' -n kube-system -o wide
```
Execute o comando kubectl logs para exibir os logs do pod do Provedor de Repositório de Segredos:
```
kubectl logs -n kube-system <provider-pod-name> --since=1h | grep ^E
```
Execute o comando kubectl logs para exibir os logs do pod do Driver CSI do Repositório de Segredos:
```
kubectl logs -n kube-system <csi-driver-pod-name> -c secrets-store --since=1h | grep ^E
```

Depois de coletar os logs de pod do Provedor de Repositório de Segredos e do Driver CSI, analise esses logs em relação às causas mencionadas nas seções a seguir para identificar o problema e a solução correspondente.

Observação

Se você abrir uma solicitação de suporte, é uma boa ideia incluir os logs relevantes do Provedor do Azure Key Vault e do Driver CSI do Repositório 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 avisoFalha no montador de 74s kubelet MountVolume.SetUp para o volume "secrets-store-inline": kubernetes.io/csi: mounter. Falha na configuração: erro rpc: código = Desconhecido desc = falha ao montar objetos de armazenamento de segredos para o padrão/teste do pod, err: erro rpc: código = Desconhecido desc = falha ao montar objetos, erro: falha ao obter o cliente do cofre de chaves: falha ao obter o token do cofre de chaves: falha na resposta nmi com o código de status: 404, err: <nulo>

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

Solução 1: Verificar os logs do pod NMI

Para obter mais informações sobre esse erro e como resolvê-lo, verifique os logs de pod NMI e consulte o guia de solução de problemas de identidade de pod do 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:

E1029 17:37:42.461313 1 server.go:54] falha ao processar a solicitação de montagem, erro: keyvault. BaseClient#GetSecret: Falha ao enviar solicitação: 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 do host. Uma falha pode ocorrer se uma política estiver bloqueando esse tráfego ou se ocorrerem instabilidade de rede no nó.

Solução 2: Verifique as políticas de rede, a lista de permissões e a conexão do 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 a ID do Microsoft Entra e seu cofre de chaves.

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

Crie 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

Execute kubectl exec para executar um comando no pod que você criou:
```
kubectl exec --stdin --tty  curl -- sh
```

Autentique 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'

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 código de erro HTTP "400" acompanhada por uma descrição de erro "Identidade não encontrada", a identidade gerenciada atribuída pelo usuário está incorreta em seu SecretProviderClass recurso personalizado. A resposta completa é semelhante 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: Atualize SecretProviderClass usando o valor correto de userAssignedIdentityID

Localize 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 encontrar a identidade gerenciada atribuída pelo usuário correta, 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 artigo Fornecer uma identidade para acessar o Provedor do Azure Key Vault para o Driver CSI do Repositório de Segredos .

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

O acesso à rede pública não é permitido no nível do Azure Key Vault e a conectividade entre o AKS e o 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 semelhante 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"}

Solução 4a: configurar um link de rede virtual e emparelhamento de rede virtual para conectar as redes virtuais

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

Crie um link de rede virtual para a rede virtual do cluster do AKS no nível da zona DNS privada do Azure.
Adicione o emparelhamento de rede virtual entre a rede virtual do cluster do AKS e a rede virtual do ponto de extremidade privado do Key Vault.

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

Etapa 1: Criar o link de rede virtual

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 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 do Key Vault provavelmente será resolvido por meio de um endereço IP público. Para verificar 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 do comando será semelhante 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 do AKS no nível da zona DNS privada. (Um link de rede virtual já foi criado automaticamente para a rede virtual do ponto de extremidade privado do Key Vault.)

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

No portal do Azure, pesquise e selecione Zonas DNS privadas.
Na lista de zonas DNS privadas, selecione o nome da sua zona DNS privada. Neste exemplo, a zona DNS privada é privatelink.vaultcore.azure.net.
No painel de navegação da zona DNS privada, localize o cabeçalho Configurações e selecione Links de rede virtual.
Na lista de links de rede virtual, selecione Adicionar.

Na página Adicionar link de rede virtual, preencha 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 que contenha o link de rede virtual.
Rede virtual	Selecione o nome da rede virtual do cluster do AKS.

Selecione o botão OK.

Depois de concluir o procedimento de criação do link, execute o nslookup comando. A saída agora deve ser semelhante 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 do 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 semelhante 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:

Acesse o portal do Azure.
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 do portal do Azure para emparelhar as redes virtuais e verificar se as redes virtuais estão conectadas (de uma extremidade):
- Vá para a rede virtual do AKS e emparelhe-a com a rede virtual do ponto de extremidade privado do Key Vault.
- Vá para a rede virtual do ponto de extremidade privado do Key Vault e emparelhe-o com a rede virtual do AKS.
No portal do Azure, pesquise e selecione o nome da outra rede virtual (a rede virtual que você emparelhou na etapa anterior).
No painel de navegação da rede virtual, localize o título Configurações e selecione Emparelhamentos.
Na página de emparelhamento de rede virtual, verifique se a coluna Nome contém o nome do link de emparelhamento da rede virtual remota que você especificou na etapa 2. Além disso, verifique se a coluna Status de emparelhamento desse link de emparelhamento tem um valor de Conectado.

Depois de concluir este procedimento, você pode executar o comando Netcat novamente. A resolução DNS e a conectividade entre o AKS e o Key Vault agora devem ser bem-sucedidas. Além disso, verifique se os segredos do Key Vault foram montados com êxito e funcionam 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

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

Causa 5: o driver secrets-store.csi.k8s.io não se encontra na 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 do Repositório de Segredos não estarão em execução no nó no qual o aplicativo está sendo executado:

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

Solução 5: Solucionar problemas do pod do driver CSI do repositório secreto em execução no mesmo nó

Recupere o status do pod do driver CSI do repositório secreto em execução no mesmo nó executando o seguinte comando:

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

Se o status do pod não Running for ou qualquer um dos contêineres neste pod não estiver no Ready estado, prossiga para verificar os logs desse pod seguindo as etapas em Verificar os logs de pod do Provedor de Repositório de Segredos e do Driver CSI.

Causa 6: SecretProviderClass não encontrado

Você pode ver o seguinte evento ao descrever o pod do aplicativo:

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

Esse evento indica que o referenciado SecretProviderClass na especificação de volume do pod não existe no mesmo namespace que o pod do aplicativo.

Solução 6a: Criar o recurso SecretProviderClass ausente

Verifique se o SecretProviderClass recurso referenciado na especificação de volume do pod existe no mesmo namespace em que o pod do aplicativo está sendo executado.

Solução 6b: Modifique a especificação de volume do pod do aplicativo para fazer referência ao nome correto do recurso SecretProviderClass

Edite a especificação de volume do pod de aplicativos para fazer referência ao nome correto SecretProviderClass do recurso:

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

Causa 7: a solicitação não está autenticada

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

Solução 7: Solucionar problemas do código de erro 401

Solucione problemas do código de erro "401" examinando a seção "HTTP 401: solicitação não autenticada" do artigo de referência Códigos de erro da API REST do Azure Key Vault.

Causa 8: 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 8: solucionar problemas do código de erro 429

Solucione problemas do código de erro "429" examinando a seção "HTTP 429: muitas solicitações" do artigo de referência Códigos de erro da API REST do Azure Key Vault.

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.

Compartilhar via