Resolver problemas do provedor OIDC

Neste documento, fornecemos orientações para resolver problemas com o provedor de identidade do OIDC e AzureAD no GKE Identity Service.

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 encoded

  • Certificado 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 de certificação raiz, será necessário configurar o GKE Identity Service com 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 issuer do certificado do servidor não corresponde ao subject do 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 certificate

  • A 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 certificate

  • A 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 principal 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 do tamanho dos nomes dos grupos).

Esse token grande faz com que a execução dos comandos kubectl falhe porque excede o tamanho máximo da linha de comando permitido 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 do cluster do GKE

    Se você estiver executando uma versão do cluster do GKE anterior à 1.28, recomendamos que faça upgrade para a versão com suporte.

  • Reduzir as associações a grupos do usuário afetado

    Reduzir o número de grupos a que o usuário autenticado pertence abaixo do limite problemático (aproximadamente 70 grupos) pode resolver o problema.

  • Aumentar as associações a grupos 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 a grupos pode causar problemas de autenticação. No entanto, é possível resolver os problemas do provedor de identidade aumentando o número de associações a grupos além desse limite. Devido ao comportamento desse limite, o Azure AD omite grupos do id_token quando o número de associações fica muito grande, evitando que a linha de comando fique muito longa e resolvendo os problemas do provedor de identidade. Consulte a documentação do Microsoft Entra ID para confirmar o limite e saber mais detalhes.