Solução de problemas de segredos externos

Soluções para problemas do operador de segredos externos no Automation Suite no EKS/AKS.

Visão geral

Esta seção fornece etapas de solução de problemas para resolver problemas relacionados ao Operador de segredos externos e à configuração do armazenamento de segredos no Automation Suite.

Para identificar e resolver problemas de sincronização ou autenticação entre seu cluster e o provedor de segredo externo, siga as etapas descritas nesta seção.

Verifique o status e os logs do pod de segredos externos

Comece verificando se os pods do Operador de segredos externos estão sendo executados corretamente.

Se os pods não estiverem no estado Em execução ou mostrarem reinicializações repetidas, revise seus logs para obter quaisquer erros relacionados a autenticação, permissões ou configuração incorreta.

Para verificar o status dos pods de Segredos externos e visualizar seus logs, execute:

kubectl get pods -A | grep external-secrets
kubectl logs -f <pod-name> -n <namespace>

Por exemplo, para visualizar logs de um pod específico, execute:

kubectl logs -f external-secrets-7d8c9b5f9f-abc12 -n external-secrets

Inspecionar objetos SecretStore e ExternalSecret

Se os pods estiverem sendo executados corretamente, verifique se os recursos SecretStore e ExternalSecret estão configurados e sincronizados corretamente.

Esses recursos definem como os segredos externos são recuperados e armazenados, portanto, qualquer configuração incorreta pode impedir a sincronização bem-sucedida.

• Verifique os recursos ExternalSecret Comece revisando os objetos ExternalSecret em seu cluster. Isso ajuda a confirmar que os recursos estão corretamente vinculados ao seu SecretStore e que o status de sincronização é válido.
  • Para exibir e inspecionar seus recursos ExternalSecret, execute os seguintes comandos:

    kubectl get externalsecrets -A
    kubectl describe externalsecret <externalsecret-name> -n <namespace>
    

  • Por exemplo, para revisar um ExternalSecret específico no namespace uipath :

    kubectl describe externalsecret azure-secret-store -n uipath
    

• Verificar recursos do SecretStore Inspecione a configuração do SecretStore associada. Esse recurso define os detalhes da conexão para seu provedor de segredos (como o Azure Key Vault), e os erros aqui podem bloquear a sincronização de segredos.
  • Para revisar as definições do SecretStore, use os seguintes comandos:

    kubectl get secretstores -A
    kubectl describe secretstore <secretstore-name> -n <namespace>
    

  • Por exemplo, para examinar uma configuração do SecretStore no namespace uipath :

    kubectl describe secretstore azure-secretstore -n uipath
    

• Verifique eventos relacionados aos Segredos externos Revise quaisquer eventos do Kubernetes relacionados ao Operador de segredos externos. Esses eventos podem revelar falhas de sincronização, problemas de permissão ou configurações incorretas do provedor.

  • Para visualizar eventos relacionados, execute o seguinte comando:

    kubectl get events -A | grep external-secrets
    

    Ao revisar a saída do evento, procure:

    • Mensagens de erro na seção Status
    • Condições que indicam se Ready: True
    • Avisos ou falhas de sincronização na seção Eventos

Verificar credenciais do armazenamento secreto

Se você estiver usando o Azure Key Vault como seu provedor de segredo, certifique-se de que as credenciais e a configuração sejam válidas e atualizadas.

Credenciais incorretas ou permissões ausentes são causas comuns de falhas de sincronização.

• Credenciais de autenticação
  • Confirme se os valores clientId, clientSecret e tenantId estão corretos.
  • Certifique-se de que a entidade de serviço tenha as permissões necessárias para o Key Vault.
• Políticas de acesso ao Key Vault
  • Verifique as permissões Get e List para os segredos.
  • Certifique-se de que as configurações do firewall do Key Vault permitam o acesso de seu cluster.
• Configuração de identidade da carga de trabalho (se aplicável)
  • Verifique se as credenciais federadas estão configuradas corretamente.
  • Certifique-se de que a conta de serviço associada tenha as anotações necessárias.
• Uri do Cofre de Chaves

  • Verifique se o vaultUrl em sua configuração do SecretStore está correto.

    Exemplo de formato:

    https://<key-vault-name>.vault.azure.net/
    

Verifique as permissões da entidade de serviço do Azure Key Vault

Se sua implantação usa uma entidade de serviço, confirme se ela tem acesso para recuperar segredos do Azure Key Vault.

Para listar os segredos acessíveis à sua entidade de serviço, execute:

az keyvault secret list --vault-name <key-vault-name>

Verifique a conectividade e a autenticação do HashiCorp Vault

Se você estiver usando o HashiCorp Vault como seu provedor de segredos, verifique o seguinte:

• Teste a acessibilidade do servidor do Vault Confirme se o URL do servidor do Vault na sua configuração do SecretStore é acessível a partir de um nó ou jumphost que tenha acesso de rede ao cluster:

  curl -sk https://<vault-server>:8200/v1/sys/health
  

  Um Vault íntegro retorna uma resposta JSON com "initialized": true e "sealed": false. Se o comando atingir o tempo limite ou retornar connection refused, verifique as políticas de rede e as regras de firewall entre o cluster e o servidor do Vault.

• Verificar o status do selo do Vault

  curl -sk https://<vault-server>:8200/v1/sys/seal-status
  

  Se "sealed": true, o servidor do Vault deve ser removido antes que o ESO possa recuperar os segredos.

• Teste o login da autenticação do Kubernetes Se estiver usando auth_type: kubernetes, verifique se um token de conta de serviço pode se autenticar no Vault. Primeiro, extraia o token do pod do ESO:

  ESO_POD=$(kubectl get pods -n uipath -l app.kubernetes.io/name=external-secrets -o jsonpath='{.items[0].metadata.name}')
  JWT=$(kubectl exec -n uipath $ESO_POD -- cat /var/run/secrets/kubernetes.io/serviceaccount/token)
  

  Em seguida, teste o login:

  curl -sk --request POST \
    --data "{\"jwt\": \"$JWT\", \"role\": \"<vault-role>\"}" \
    https://<vault-server>:8200/v1/auth/<mount-path>/login
  

  Uma resposta bem-sucedida contém um client_token. Um erro permission denied indica que a função Vault não permite a conta de serviço ou que o método de autenticação do Kubernetes está configurado incorretamente.

• Testar login da autenticação do AppRole Se estiver usando auth_type: approle, verifique as credenciais do AppRole:

  curl -sk --request POST \
    --data '{"role_id": "<role-id>", "secret_id": "<secret-id>"}' \
    https://<vault-server>:8200/v1/auth/<mount-path>/login
  

  Se isso falhar, verifique se o AppRole secret-id não expirou (secret_id_ttl).

• Verifique se o segredo de credenciais do AppRole existe

  kubectl get secret <credentials-secret-name> -n uipath -o json | jq '.data | keys'
  

  O segredo deve conter as chaves role-id e secret-id .

• Teste a leitura de um segredo do Vault KV v2 usando um token do Vault obtido das etapas de autenticação acima:

  curl -sk -H "X-Vault-Token: <vault-token>" \
    https://<vault-server>:8200/v1/<kv-path>/data/<secret-path>
  

  Para o KV v1, remova /data/ do caminho. Se a resposta for no value found at path, verifique se hashicorp_kv.version corresponde à versão real do mecanismo.

• Verificar a versão do mecanismo KV Certifique-se de que hashicorp_kv.version em sua configuração corresponda à versão real do mecanismo KV habilitada no Vault (v1 ou v2). Uma incompatibilidade produz erros no value found at path porque v1 e v2 usam caminhos de API diferentes.

• Verifique a configuração de autenticação do Kubernetes Certifique-se de que o método de autenticação do Kubernetes do Vault esteja habilitado e configurado com o kubernetes_host correto. Verifique se a função do Vault permite a conta de serviço do ESO (ou personalizado service_account_name).

Verificar a conectividade e as permissões do AWS Secrets Manager

Se você estiver usando o AWS Secrets Manager como seu provedor de segredos, verifique o seguinte:

• Verifique se o segredo das credenciais da chave de acesso existe

  kubectl get secret <credentials-secret-name> -n uipath -o json | jq '.data | keys'
  

  O segredo deve conter as chaves access-key-id e secret-access-key .

• Teste o acesso do AWS Secrets Manager usando as credenciais da chave de acesso, verifique se o segredo pode ser recuperado:

  aws secretsmanager get-secret-value \
    --secret-id <secret-name> --region <region>
  

  • AccessDeniedException - o usuário de IAM não tem permissão secretsmanager:GetSecretValue .
  • ResourceNotFoundException - o segredo não existe na região especificada. Verifique o valor aws_kv.region .

• Verifique a configuração da região Verifique se o valor aws_kv.region corresponde à região na qual seus segredos estão armazenados. Uma incompatibilidade de região produz erros ResourceNotFoundException .

Problemas de certificado TLS e CA

Quando o endpoint do Vault ou da AWS usar HTTPS com um certificado de CA privado, verifique o seguinte:

• Verifique se o segredo do certificado de CA adicional existe

  kubectl get secret additional-ca-certificates -n uipath
  

• Verifique o conteúdo do certificado CA

  kubectl get secret additional-ca-certificates -n uipath -o jsonpath='{.data.ca\.crt}' | base64 -d | openssl x509 -text -noout
  

  Verifique se o certificado não expirou e se o emissor corresponde à CA usada por seu endpoint do Vault ou da AWS.

• Testar handshake de TLS

  curl -v https://<vault-server>:8200/v1/sys/health
  

  Se você vir SSL certificate problem: unable to get local issuer certificate, o certificado da CA não é confiável. Verifique se additional_ca_certs está configurado em input.json. Para testar com um arquivo de certificado de CA específico:

  curl -v --cacert /path/to/ca.crt https://<vault-server>:8200/v1/sys/health
  

Problemas comuns de configuração

Revise os seguintes problemas comuns e mensagens de erro correspondentes para ajudar a diagnosticar o problema.

Issue	Possível causa	Exemplo de saída de erro
Segredo não encontrado no cluster	Segredo do Kubernetes ausente	Warning InvalidProviderConfig 3s (x4 over 8s) secret-store cannot get Kubernetes secret "azure-service-principal-secret" from namespace "uipath": secrets "azure-service-principal-secret" not found
Credenciais inválidas	ID do cliente, segredo do cliente ou ID de tenant incorreto	error processing spec.data[0] (key: external-object-storage-account-key-10176524), err: azure.BearerAuthorizer#WithAuthorization: Failed to refresh the Token for request ... StatusCode=400
Objeto do Cofre de Chaves ausente	Chave ausente no Azure Key Vault	external-secrets error processing spec.data[0] (key: external-object-storage-account-key), err: Secret does not exist
HashiCorp Vault inacessível	URL incorreta do servidor ou política de rede que bloqueia o acesso	connection refused ou context deadline exceeded
Falha na autenticação do cofre	Conta de serviço do Kubernetes não associada à função Vault ou AppRole expirado secret-id	permission denied
Incompatibilidade de versão do KV	hashicorp_kv.version definida como v2 , mas o mecanismo é v1 (ou vice-versa)	no value found at path
Credenciais da AWS inválidas	ID da chave de acesso ou chave de acesso secreta incorreta	InvalidClientTokenId ou SignatureDoesNotMatch
Segredo da AWS não encontrado	O segredo não existe na região configurada ou incompatibilidade de região	ResourceNotFoundException

Para investigar mais a fundo esses problemas, revise os logs do controlador ou descreva os recursos relacionados:

kubectl describe externalsecret <name> -n <namespace>
kubectl describe secretstore <name> -n <namespace>