Este documento fornece orientações para resolver problemas com o provedor de identidade do OIDC e AzureAD ao acessar os clusters de membros da frota. Este documento se aplica apenas a tipos de clusters compatíveis.
Formatação incorreta do certificado
Esse problema ocorre quando o valor do certificado tem erros de formatação. Os problemas de formatação podem corresponder a valores de certificado não codificados em base64 e valores não codificados, mas incorretos. O problema também pode surgir se o certificado não tiver sido assinado por uma autoridade de certificação raiz ou se uma cadeia de confiança formatada corretamente não for fornecida.
Mensagens de erro
Os exemplos a seguir são de mensagens de erro para cenários em que o formato do certificado está incorreto:
Certificado não codificado em base64:
Failed creating HTTP client to fetch the Discovery URI "<Discovery-document URI>" with error: Unable to decode data field, the value should be Base64 encodedCertificado que não está formatado corretamente ou codificado em base64, mas incorreto:
Unable to connect to 'https://example.com', encountered the following error: Problem with the SSL CA cert (path? access rights?). Details: error setting certificate verify locations: CAfile: /tmp/example.pem CApath: none (The certificate could not be read, this is most likely because it's empty or contains a formatting error. Please check your configuration.)Certificado que não está formatado corretamente ou codificado em base64, mas incorreto:
Failed fetching the Discovery URI "<Discovery-document URI>" with error: Unable to load TLS certificates.
Solução
É possível resolver os problemas de uma das seguintes maneiras:
- O valor do certificado fornecido em ClientConfig deve ser uma string codificada em base64 e uma string formatada em PEM. Para mais informações, consulte Codificar certificados de CA.
- Se o provedor não usar certificados assinados por uma autoridade certificadora raiz, será necessário configurar uma cadeia de confiança de certificado. Para mais informações, consulte Certificados intermediários.
Valor de certificado incorreto
Esse problema ocorre quando o certificado tem um valor incompatível. Nesse caso, a formatação dos certificados está correta, mas eles não correspondem ao servidor. Isso também pode indicar que não há certificados na configuração.
Um valor de certificado pode ser considerado incorreto em qualquer um dos seguintes cenários:
- Um valor de certificado incorreto é compartilhado no ClientConfig. Um valor de certificado está incorreto quando o
issuerdo certificado do servidor não corresponde aosubjectdo certificado configurado. - O certificado em ClientConfig não é uma string codificada em base64.
- A cadeia de certificados não é fornecida quando certificados intermediários são usados para emitir o certificado do servidor.
Mensagem de erro
Os exemplos a seguir são de mensagens de erro para cenários em que há uma incompatibilidade no valor do certificado:
A cadeia de certificados não está completa ou não corresponde ao servidor:
SSL peer certificate was not OK. Details: SSL certificate problem: unable to get local issuer certificateA cadeia de certificados não está completa (corresponde a uma cadeia parcial inválida que não começa na raiz ou não é contígua):
Failed fetching the Discovery URI "<Discovery-document URI>" with error: The server's TLS certificate did not match expectations.A cadeia de certificados é válida, mas não corresponde ao servidor OIDC:
AIS was expecting the server to have a different certificateA cadeia de certificados é válida, mas não corresponde ao servidor OIDC:
Failed fetching the Discovery URI "<Discovery-document URI>" with error: The server's TLS certificate did not match expectations.
Solução
O valor do certificado fornecido no ClientConfig precisa incluir uma cadeia de certificados formatada corretamente que corresponda ao provedor de identidade. Para mais informações sobre como formatar e codificar certificados, consulte Codificar certificados de CA.
Os comandos kubectl falham ao usar um arquivo kubeconfig gerado pelo comando gcloud anthos auth login
Quando você usa o comando gcloud anthos auth login com o OIDC em máquinas Windows para gerar um arquivo kubeconfig para acesso ao cluster, os comandos kubectl podem falhar com a seguinte mensagem de erro: The command line is too long. Esse problema ocorre especificamente em sistemas Windows e não afeta máquinas Linux que usam o mesmo arquivo kubeconfig. A causa subjacente está relacionada ao tamanho do token de autenticação gerado pelo Azure Active Directory (Azure AD) quando um usuário pertence a um grande número de grupos (aproximadamente 70 a 200 grupos, dependendo dos comprimentos dos nomes dos grupos).
Esse token grande faz com que a execução de comandos kubectl falhe porque excede o comprimento máximo da linha de comando permitida pelo Windows, que é de 8.191 caracteres.
Mensagem de erro
$ kubectl --kubeconfig test-kubeconfig.yml get nodes The command line is too long. The command line is too long. E0102 11:02:29.115256 24320 memcache.go:265] couldn't get current server API group list: Get "https://10.35.0.86:443/api?timeout=32s": getting credentials: exec: executable gcloud failed with exit code 1 The command line is too long. E0102 11:02:29.350238 24320 memcache.go:265] couldn't get current server API group list: Get "https://10.35.0.86:443/api?timeout=32s": getting credentials: exec: executable gcloud failed with exit code 1 The command line is too long. E0102 11:02:30.062811 24320 memcache.go:265] couldn't get current server API group list: Get "https://10.35.0.86:443/api?timeout=32s": getting credentials: exec: executable gcloud failed with exit code 1 Unable to connect to the server: getting credentials: exec: executable gcloud failed with exit code 1
Solução
Para resolver esse problema, faça o seguinte:
Faça upgrade para a versão 1.28 ou mais recente
Se você estiver executando uma versão anterior à 1.28, recomendamos que faça upgrade para a versão compatível.
Reduza as associações de grupo do usuário afetado
Reduzir o número de grupos a que o usuário de autenticação pertence abaixo do limite problemático (aproximadamente 70 grupos) pode resolver o problema.
Aumente as associações de grupo do usuário afetado
O recurso do Microsoft Entra ID tem um limite para o número de grupos emitidos em um token. Ter entre 70 e 200 associações de grupo pode causar problemas de autenticação. No entanto, é possível resolver os problemas do provedor de identidade aumentando o número de associações de grupo além desse limite. Devido ao comportamento desse limite, o Azure AD omite grupos do
id_tokenquando o número de associações se torna excessivamente grande, impedindo que a linha de comando fique muito longa e, assim, resolvendo os problemas do provedor de identidade. Consulte a documentação do Microsoft Entra ID para confirmar o limite e mais detalhes.