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.

Como identificar problemas do OIDC

Quando o OIDC não está funcionando em clusters do Anthos em bare metal, geralmente é resultado de um problema de configuração na especificação do OIDC no arquivo de configuração do cluster. 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.

Como revisar os registros do Anthos Identity Service

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

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

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.
```
Se você identificou um problema de configuração nos registros, veja Como reconfigurar o OIDC.
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.

Como verificar a especificação do OIDC no cluster

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

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
```
Observação: a especificação clientconfig pode ser um pouco diferente da especificação OIDC no arquivo de configuração do cluster. Por exemplo, o URL do provedor OIDC é especificado com o campo issuerURL no arquivo de configuração do cluster, mas o objeto clientconfig retorna essa informação no campo issuerURI.
Revise os valores do campo para confirmar que a especificação está configurada corretamente para o provedor OIDC.
Se você identificou um problema de configuração na especificação, consulte Como reconfigurar o OIDC.
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.

Como reconfigurar o 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	Sim	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