Solução de problemas do OIDC em clusters do Anthos em Bare Metal

Nesta página, mostramos como identificar e resolver problemas do OpenID Connect (OIDC) com clusters Anthos em bare metal.

Identificar problemas do OIDC

Se o OIDC não está funcionando em clusters do Anthos em bare metal, geralmente a especificação do OIDC no arquivo de configuração do cluster foi configurada incorretamente. Nesta seção, fornecemos instruções para analisar registros e a especificação do OIDC para ajudar a identificar a causa de um problema do OIDC.

Revisar os registros do Anthos Identity Service

O Anthos Identity Service é compatível com OIDC em clusters do Anthos em Bare Metal.

  1. Use kubectl logs para imprimir os registros do Anthos Identity Service:

    kubectl --kubeconfig CLUSTER_KUBECONFIG -n anthos-identity-service logs \
    deployment/ais --all-containers=true
    
  2. Analise os registros em busca de erros que possam ajudar a diagnosticar problemas do OIDC.

    Se você não conseguir se autenticar com o OIDC, os registros do Anthos Identity Service fornecerão as informações mais relevantes e úteis para depurar o problema.

    Por exemplo, se a especificação OIDC (no arquivo de configuração do cluster) tiver um erro de digitação no campo issuerURL, como htps://accounts.google.com (um "t" está ausente em https), os registros do Anthos Identity Service conterão uma entrada como esta:

    OIDC (htps://accounts.google.com) - Unable to fetch JWKs needed to validate OIDC ID token.
    
  3. Se você identificou um problema de configuração nos registros, veja Como reconfigurar o OIDC.

  4. Se você não conseguir diagnosticar e resolver o problema por conta própria, entre em contato com o Cloud Customer Care.

    O Cloud Customer Care precisará dos registros do Anthos Identity Service e da especificação OIDC para diagnosticar e resolver problemas do OIDC.

Verificar a especificação do OIDC no seu cluster

As informações do OIDC do cluster são especificadas no objeto clientconfig no namespace kube-public.

  1. Use kubectl get para imprimir o recurso OIDC para o cluster:

    kubectl --kubeconfig CLUSTER_KUBECONFIG -n kube-public get \
    clientconfig.authentication.gke.io default -o yaml
    
  2. Revise os valores do campo para confirmar que a especificação está configurada corretamente para o provedor OIDC.

  3. Se você identificou um problema de configuração na especificação, consulte Como reconfigurar o OIDC.

  4. Se você não conseguir diagnosticar e resolver o problema por conta própria, entre em contato com o Cloud Customer Care.

    O Cloud Customer Care precisará dos registros do Anthos Identity Service e da especificação do OIDC para diagnosticar e resolver problemas do OIDC.

Reconfigurar OIDC

Se você identificou problemas nos registros do Anthos Identity Service ou no objeto clientconfig, é possível reconfigurar o OIDC no cluster (sem recriar o cluster) para resolvê-los. Para reconfigurar o OIDC, edite o objeto padrão do KRM do tipo clientconfig no namespace kube-public:

kubectl --kubeconfig CLUSTER_KUBECONFIG -n kube-public edit clientconfig default

Os detalhes do ClientConfig CRD são usados para configurar o OIDC do console do Google Cloud e do plug-in de autenticação para o Anthos. Para detalhes sobre as informações do OIDC incluídas no CRD do ClientConfig, consulte o YAML a seguir e a tabela associada das descrições de campos.

authentication:
  - name: oidc
    oidc:
      certificateAuthorityData: CERTIFICATE_STRING
      clientID: CLIENT_ID
      clientSecret: CLIENT_SECRET
      cloudConsoleRedirectURI: "http://console.cloud.google.com/kubernetes/oidc"
      deployCloudConsoleProxy: PROXY_BOOLEAN
      extraParams: EXTRA_PARAMS
      groupsClaim: GROUPS_CLAIM
      groupPrefix: GROUP_PREFIX
      issuerURI: ISSUER_URI
      kubectlRedirectURI: KUBECTL_REDIRECT_URI
      scopes: SCOPES
      userClaim: USER_CLAIM
      userPrefix: USER_PREFIX
    proxy: PROXY_URL

A tabela a seguir descreve os campos do objeto oidc do ClientConfig CRD.

Campo Obrigatório Descrição Formato
Nome Sim O nome da configuração do OIDC a ser criada. String
certificateAuthorityData Não

Um certificado codificado em PEM codificado por base64 para o provedor OIDC. Para criar a string, codifique o certificado, incluindo cabeçalhos, em base64. Inclua a string resultante em certificateAuthorityData como uma única linha.

Exemplo:
certificateAuthorityData: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tC...k1JSUN2RENDQWFT==

String
clientID Sim ID do aplicativo cliente que faz solicitações de autenticação para o provedor OpenID. String
clientSecret Não Senha secreta entre o aplicativo cliente OIDC e o provedor OIDC. String
parâmetros extras Não

Parâmetros de chave-valor extras a serem enviados ao provedor OpenID. Se você estiver autorizando um grupo, transmita resource=token-groups-claim.

Se o servidor de autorização solicitar consentimento para autenticação com o Microsoft Azure e o Okta, defina extraParams como prompt=consent. Para o Cloud Identity, defina extraParams como prompt=consent,access_type=offline.

Lista delimitada por vírgulas
groupsClaim Não Declaração do JWT que o provedor usa para retornar grupos de segurança. String
groupPrefix Não Prefixo anexado a declarações de grupo para evitar conflitos com nomes existentes. Por exemplo, se você tiver dois grupos chamados foobar, adicione um prefixo gid-. O grupo resultante é gid-foobar. String
issuerURI Sim URL ao qual são enviadas solicitações de autorização para seu OpenID, como https://example.com/adfs. O servidor da API Kubernetes usa esse URL a fim de descobrir chaves públicas para verificação de tokens. O URI precisa usar HTTPS. String do URL
kubectlRedirectURI Sim O URL de redirecionamento que kubectl usa para autorização. String do URL
scopes Sim Outros escopos a serem enviados ao provedor OpenID. O Microsoft Azure e o Okta exigem o escopo offline_access. Lista delimitada por vírgulas
userClaim Não Declaração do JWT a ser usada como nome de usuário. É possível escolher outras declarações, como e-mail ou nome, dependendo do provedor OpenID. No entanto, as declarações diferentes de e-mail são prefixadas com o URL do emissor para evitar conflitos de nomenclatura. String
userPrefix Não Prefixo anexado a declarações de nome de usuário para evitar conflitos com nomes que já existem. String
proxy Não Servidor proxy a ser usado para o método auth, se aplicável. Exemplo: http://user:password@10.10.10.10:8888. String