Como autenticar com o OIDC e o Google

Saiba como configurar o OpenID Connect (OIDC) em clusters Anthos em Bare Metal e usar o Google como provedor OpenID.

Para uma visão geral do fluxo de autenticação do Anthos em Bare Metal, consulte Autenticação. Consulte os tópicos a seguir para saber como configurar o OIDC com outros provedores OpenID:

Visão geral

Os clusters do Anthos em Bare Metal são compatíveis com o OIDC como um dos mecanismos de autenticação para interagir com o servidor da API Kubernetes de um cluster. O OIDC permite gerenciar o acesso aos clusters do Kubernetes usando os procedimentos padrão na organização para criar, ativar e desativar contas de usuário.

Há duas maneiras de os usuários autorizarem contas:

  • Use o Google Cloud CLI para iniciar o fluxo do OIDC e receber autorização do usuário em uma página de consentimento no navegador

  • Usar o console do Google Cloud para iniciar o fluxo de autenticação do OIDC.

Antes de começar

  • Este tópico pressupõe que você já conhece os seguintes conceitos de autenticação e OpenID:

  • O provedor do Google OpenID não é compatível com grupos. Ao usar o controle de acesso baseado em papéis (RBAC, na sigla em inglês) do Kubernetes para conceder papéis a usuários autenticados, é preciso conceder papéis a cada usuário, não a um grupo.

  • Os sistemas headless não são compatíveis. Um fluxo de autenticação baseado em navegador é usado para solicitar consentimento e autorizar a conta de usuário.

  • Para autenticar por meio do Console do Google Cloud, cada cluster que você quer configurar para autenticação OIDC precisa ser registrado no Google Cloud.

Perfis

Este tópico se refere a três perfis:

  • Administrador da organização: essa pessoa escolhe um provedor OpenID e registra aplicativos cliente com o provedor.

  • Administrador de cluster: esta pessoa cria um ou mais clusters e cria arquivos de configuração de autenticação para desenvolvedores que usam os clusters.

  • Desenvolvedor: essa pessoa executa cargas de trabalho em um ou mais clusters e usa o OIDC para fazer a autenticação.

Como criar URLs de redirecionamento

Esta seção é destinada a administradores da organização.

É necessário criar URLs de redirecionamento para a CLI e para o Console do Cloud usado pelo provedor OpenID no retorno dos tokens de ID.

URL de redirecionamento da CLI gcloud

A Google Cloud CLI é instalada na máquina local de cada desenvolvedor e inclui a CLI gcloud. É possível especificar um número de porta maior que 1.024 para usar no URL de redirecionamento:

http://localhost:[PORT]/callback

em que [PORT] é o número da porta.

Ao configurar o provedor Google OpenID, especifique http://localhost:[PORT]/callback como um dos seus URLs de redirecionamento.

URL de redirecionamento do Console do Google Cloud

O URL de redirecionamento do console do Google Cloud é:

https://console.cloud.google.com/kubernetes/oidc

Ao configurar o provedor Google OpenID, especifique https://console.cloud.google.com/kubernetes/oidc como um dos seus URLs de redirecionamento.

Nesta seção, você configura a tela de consentimento do OAuth do Google. Quando um desenvolvedor em sua organização inicia a autenticação em um cluster, ele é direcionado para essa tela de consentimento. Nesse momento, ele prova sua identidade e dá permissão ao Google para criar um token que fornece informações de identificação ao cliente OAuth. No contexto deste tópico, o cliente OAuth é a CLI gcloud ou o Console do Google Cloud.

  1. Acesse a página Tela de consentimento OAuth no Console do Google Cloud.

    Configure a tela de consentimento OAuth

  2. Selecione Interno e clique em Criar.

  3. Em Tipo de aplicativo, selecione Interno.

  4. Em Nome do aplicativo, insira um nome de sua escolha. Sugestão: bare metal.

  5. Em Domínios autorizados, adicione google.com.

  6. Preencha os campos adicionais conforme achar adequado.

  7. Clique em Save.

Como registrar um aplicativo cliente no Google

Nesta seção, você registrará os clusters do Anthos em Bare Metal com o Google para que o Google possa atuar como o provedor OpenID para os desenvolvedores na sua organização. Como parte do registro, você precisa fornecer os dois URLs de redirecionamento criados anteriormente.

  1. Acesse a página Credenciais no Console do Google Cloud.

    Acessar a página Credenciais

  2. Clique em Criar credenciais e selecione ID do cliente do OAuth.

  3. Em Tipo de aplicativo, selecione Aplicativo da Web.

  4. Em Nome, digite um nome de sua escolha.

  5. Em URIs de redirecionamento autorizados, adicione seus dois URLs de redirecionamento. Lembre-se de que você criou um URL de redirecionamento para a CLI gcloud e um URL de redirecionamento para o Console do Google Cloud.

  6. Clique em Criar.

  7. Você recebe um ID do cliente e uma chave secreta do cliente. Salve-os para uso posterior.

Como preencher a especificação oidc no arquivo de configuração dos clusters do Anthos em Bare Metal

Esta seção é destinada aos administradores de cluster.

Antes de criar um cluster, você gera um cluster do Anthos em um arquivo de configuração Bare Metal, usando bmctl create config. A configuração inclui a especificação oidc a seguir. Preencha oidc com os valores específicos do seu provedor:

authentication:
  oidc:
    issuerURL:
    kubectlRedirectURL:
    clientID:
    clientSecret:
    username:
    usernamePrefix:
    group:
    groupPrefix:
    scopes:
    extraParams:
    proxy:
    deployCloudConsoleProxy:
    certificateAuthorityData:
  • issuerURL: defina como "https://accounts.google.com". Aplicativos clientes, como a CLI gcloud e o Console do Google Cloud, enviam solicitações de autorização a esse URL. O servidor da API Kubernetes usa esse URL para descobrir chaves públicas de verificação de tokens.
  • kubectlRedirectURL: obrigatório. O URL de redirecionamento que você configurou anteriormente para a CLI gcloud.
  • clientID: ID do aplicativo cliente que faz solicitações de autenticação ao provedor OpenID. Tanto a CLI gcloud quanto o Console do Google Cloud usam esse ID. Você recebeu esse ID quando registrou seu aplicativo cliente no Google.
  • clientSecret: secret para o aplicativo cliente. Tanto a CLI gcloud quanto o Console do Google Cloud usam esse secret. Você recebeu esse ID quando registrou seu aplicativo cliente no Google.
  • username: defina como "email".
  • usernamePrefix: opcional. Prefixo anexado a declarações de nome de usuário para evitar conflitos com nomes atuais. Se você não fornecer esse campo e username for um valor diferente de email, o prefixo será padronizado como issuerurl#. É possível usar o valor - para desativar todos os prefixos.
  • group: deixe em branco.
  • groupPrefix: deixe em branco.
  • scopes: defina como "email"
  • extraParams: defina como "prompt=consent,access_type=offline".
  • proxy: opcional. É possível especificar um servidor proxy a ser usado pelo cluster para se conectar ao provedor OIDC, se aplicável. Por exemplo, http://user:password@10.10.10.10:8888. Se deixado em branco, o padrão será sem proxy.
  • deployCloudConsoleProxy: defina como false.
  • certificateAuthorityData: deixe em branco.

Como criar uma política de RBAC para o cluster

Esta seção é destinada aos administradores de cluster.

Depois de criar um cluster, use o controle de acesso baseado em papéis (RBAC) do Kubernetes para conceder acesso a usuários de cluster autenticados. Para conceder acesso a recursos em um namespace específico, crie um Papel e um RoleBinding. Para conceder acesso a recursos em um cluster inteiro, crie um ClusterRole e um ClusterRoleBinding.

Ao usar o Google como seu provedor OpenID, você precisa conceder acesso a usuários individuais. Ele não funciona para conceder acesso a grupos. Isso ocorre porque o token que o provedor do Google OpenID retorna não tem informações sobre os grupos a que um usuário individual pertence.

Por exemplo, suponha que você queira que jane@example.com visualize todos os objetos secret por todo o cluster.

Veja um manifesto para um ClusterRole chamado secret-viewer. Uma pessoa que tem esse papel pode receber, observar e listar qualquer secret no cluster.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: secret-viewer
rules:
- apiGroups: [""]
  # The resource type for which access is granted
  resources: ["secrets"]
  # The permissions granted by the ClusterRole
  verbs: ["get", "watch", "list"]

Veja um manifesto para um ClusterRoleBinding chamado people-who-view-secrets. A vinculação concede o papel secret-viewer a um usuário chamado jane@example.com.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: people-who-view-secrets
subjects:
- kind: User
  name: jane@example.com
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-viewer
  apiGroup: rbac.authorization.k8s.io

Para criar o ClusterRole, salve o manifesto em um arquivo chamado secret-viewer-cluster-role.yaml e digite este comando:

kubectl --kubeconfig [CLUSTER_KUBECONFIG] apply -f secret-viewer-cluster-role.yaml

em que [CLUSTR_KUBECONFIG] é o arquivo kubeconfig do cluster.

Para criar o ClusterRoleBinding, salve o manifesto em um arquivo chamado secret-viewer-cluster-role-binding.yaml e digite este comando:

kubectl --kubeconfig [CLUSTER_KUBECONFIG] apply -f secret-viewer-cluster-role-binding.yaml

Como instalar a CLI gcloud

Esta seção é destinada a administradores e desenvolvedores de clusters.

Os administradores de cluster que querem criar arquivos de configuração de autenticação de cluster e todos os desenvolvedores ou usuários que precisam de autenticação com um cluster precisam instalar a Google Cloud CLI na própria máquina. Os comandos de autenticação do Anthos foram integrados à CLI gcloud como o componente anthos-auth.

Como remover plug-ins antigos

É preciso desinstalar o plug-in antigo antes de usar o componente anthos-auth da CLI gcloud. Verifique se um dos plug-ins baseados em kubectl anteriores existe na sua máquina executando o comando a seguir:

kubectl anthos version

  • Se o comando responde com Error: unknown command "anthos" for "kubectl", nenhum plug-in foi encontrado e é possível pular para a próxima seção.

  • Se uma versão 1.0beta do plug-in foi encontrada, localize o binário do plug-in e exclua-o. Execute o seguinte comando para listar o local e use esse local para remover o binário da sua máquina:

    kubectl plugin list

Como instalar a CLI gcloud e a CLI gcloud

Para instalar a CLI gcloud, é necessário primeiro instalar a CLI gcloud:

  1. Instale a CLI gcloud, mas ignore o comando gcloud init.

  2. Execute os comandos a seguir para instalar o componente anthos-auth:

    gcloud components update
gcloud components install anthos-auth

  3. Verifique se a CLI gcloud foi instalada com sucesso executando um dos comandos a seguir:

    gcloud anthos auth
gcloud anthos auth login

    Resultado: cada comando responderá com detalhes sobre os argumentos necessários e as opções disponíveis.

Como criar e distribuir o arquivo de configuração de autenticação

Esta seção é destinada aos administradores de cluster.

Depois de criar um cluster, crie um arquivo de configuração de autenticação para esse cluster. É possível configurar vários clusters em um arquivo de configuração de autenticação. Forneça cada arquivo de configuração de autenticação para os usuários que quiserem se autenticar com cada um desses clusters.

Como criar o arquivo de configuração de autenticação

Para criar o arquivo de configuração de autenticação no diretório atual, execute o seguinte comando gcloud:

gcloud anthos create-login-config --kubeconfig [CLUSTER_KUBECONFIG]

[CLUSTER_KUBECONFIG] é o caminho do arquivo kubeconfig do cluster. Quando você executou bmctl create cluster para criar o cluster, o arquivo kubeconfig foi criado.

Resultado: seu arquivo de configuração de autenticação, chamado kubectl-anthos-config.yaml, é criado no diretório atual.

Como adicionar vários clusters ao arquivo de configuração de autenticação

É possível armazenar os detalhes de configuração de autenticação para vários clusters em um único arquivo de configuração de autenticação.

Use o comando a seguir para mesclar outros detalhes de autenticação de cluster em um arquivo de configuração de autenticação atual. Nesse arquivo, é possível mesclar ou combinar outros detalhes de autenticação de cluster:

  • Mesclar outros detalhes de autenticação de cluster no arquivo de configuração atual.
  • Combinar os outros detalhes de autenticação do cluster em um novo arquivo.

Por exemplo, talvez seja necessário gerenciar os arquivos de configuração de autenticação anthos-config-1cluster.yaml e anthos-config-3clusters.yaml para acomodar as necessidades de acesso dos vários grupos de usuários na sua organização.

Para adicionar mais clusters ao arquivo de configuração de autenticação atual, faça o seguinte:

  1. Verifique se cada cluster tem um nome exclusivo. Se os clusters tiverem os mesmos nomes, não será possível combiná-los no mesmo arquivo de configuração de autenticação. Após a criação de um cluster, ele não pode ser renomeado.

  2. Execute o comando gcloud a seguir para mesclar ou combinar detalhes de configuração:

    gcloud anthos create-login-config --kubeconfig [CLUSTER_KUBECONFIG] \
--merge-from [IN_AUTH_CONFIG_FILE] --output [OUT_AUTH_CONFIG_FILE]

    onde

    • [CLUSTER_KUBECONFIG] especifica o arquivo kubeconfig do cluster que você quer adicionar.

    • [IN_AUTH_CONFIG_FILE] especifica o caminho do arquivo de configuração de autenticação atual que você quer mesclar com outras informações do cluster;

    • [OUT_AUTH_CONFIG_FILE] especifica o caminho do arquivo onde você quer armazenar a configuração de autenticação mesclada:

      • Especifique o mesmo arquivo como [IN_AUTH_CONFIG_FILE] para mesclar outras informações do cluster nesse arquivo atual.
      • Especifique um novo caminho e nome de arquivo para combinar os detalhes de configuração de autenticação em um novo arquivo.

Como distribuir o arquivo de configuração de autenticação

Para permitir que os usuários se autentiquem nos clusters, forneça acesso a um ou mais arquivos de configuração de autenticação criados. As etapas a seguir usam o nome de arquivo padrão e o local esperado pela CLI gcloud. Para informações sobre como usar nomes de arquivos e locais alternativos, consulte Configuração personalizada.

Considere distribuir os arquivos de configuração de autenticação da seguinte maneira:

  • Hospedando o arquivo em um URL acessível. Se você incluir a sinalização --login-config no comando gcloud anthos auth login, a CLI gcloud receberá o arquivo de configuração de autenticação desse local.

    Considere hospedar o arquivo em um host seguro. Consulte a sinalização --login-config-cert da CLI gcloud para ver mais informações sobre o uso de certificados PEM para acesso HTTPS seguro.

  • Fornecendo manualmente o arquivo para cada usuário. Depois que os usuários fizerem o download do arquivo, informe-os sobre como armazená-lo no local padrão e com o nome de arquivo padrão esperado pela CLI gcloud.

    Por exemplo, os usuários podem executar os comandos a seguir para armazenar o arquivo de configuração de autenticação com o nome de arquivo kubectl-anthos-config.yaml padrão e no local padrão:

    Linux

    mkdir -p  $HOME/.config/google/anthos/
cp [AUTH_CONFIG_FILE] $HOME/.config/google/anthos/kubectl-anthos-config.yaml

    [AUTH_CONFIG_FILE] é o nome do arquivo de configuração de autenticação. Por exemplo, kubectl-anthos-config.yaml.

    macOS

    mkdir -p  $HOME/Library/Preferences/google/anthos/
cp [AUTH_CONFIG_FILE] $HOME/Library/Preferences/google/anthos/kubectl-anthos-config.yaml

    [AUTH_CONFIG_FILE] é o nome do arquivo de configuração de autenticação. Por exemplo, kubectl-anthos-config.yaml.

    Windows

    md "%APPDATA%\google\anthos"
copy [AUTH_CONFIG_FILE] "%APPDATA%\google\anthos\kubectl-anthos-config.yaml"

    [AUTH_CONFIG_FILE] é o nome do arquivo de configuração de autenticação. Por exemplo, kubectl-anthos-config.yaml.

  • Usar suas ferramentas internas para enviar o arquivo de configuração de autenticação para a máquina de cada usuário. Por exemplo, é possível usar suas ferramentas para enviar arquivos usando o nome de arquivo kubectl-anthos-config.yaml padrão nos locais padrão de cada máquina de usuário:

    Linux

    $HOME/.config/google/anthos/kubectl-anthos-config.yaml

    macOS

    $HOME/Library/Preferences/google/anthos/kubectl-anthos-config.yaml

    Windows

    %APPDATA%\google\anthos\kubectl-anthos-config.yaml

Configuração personalizada

A CLI gcloud espera que o arquivo de configuração de autenticação seja armazenado no local padrão e com o nome de arquivo padrão kubectl-anthos-config.yaml, conforme mencionado na seção anterior. No entanto, você tem a opção de renomear ou armazená-lo em um local alternativo. Se o nome e o local do arquivo forem diferentes do padrão, anexe a sinalização --login-config a cada comando executado ao autenticar com o cluster. A sinalização de comando extra passa no caminho personalizado e no nome de arquivo. Para saber mais sobre a sinalização de comando, consulte Como autenticar com a CLI gcloud.

Como conseguir o arquivo de configuração de autenticação

Esta seção é destinada a desenvolvedores.

O administrador é responsável por criar o arquivo de configuração de autenticação e fornecê-lo a você. Para mais detalhes, consulte Como distribuir o arquivo de configuração de autenticação.

Por padrão, a CLI gcloud usa um nome de arquivo e um local de armazenamento padrão para o arquivo de configuração de autenticação. Se você tiver fornecido o arquivo manualmente e precisar salvá-lo na sua máquina, use os padrões para simplificar os comandos de autenticação gcloud.

Use os comandos a seguir para copiar o arquivo de configuração de autenticação para o local padrão:

Linux

mkdir -p  $HOME/.config/google/anthos/
cp [AUTH_CONFIG_FILE] $HOME/.config/google/anthos/kubectl-anthos-config.yaml

[AUTH_CONFIG_FILE] é o nome do arquivo de configuração de autenticação. Por exemplo, kubectl-anthos-config.yaml.

macOS

mkdir -p  $HOME/Library/Preferences/google/anthos/
cp [AUTH_CONFIG_FILE] $HOME/Library/Preferences/google/anthos/kubectl-anthos-config.yaml

[AUTH_CONFIG_FILE] é o nome do arquivo de configuração de autenticação. Por exemplo, kubectl-anthos-config.yaml.

Windows

md "%APPDATA%\google\anthos"
copy [AUTH_CONFIG_FILE] "%APPDATA%\google\anthos\kubectl-anthos-config.yaml"

[AUTH_CONFIG_FILE] é o nome do arquivo de configuração de autenticação. Por exemplo, kubectl-anthos-config.yaml.

Se você optar por usar um nome de arquivo ou local diferente, terá a opção de incluir a sinalização --login-config em cada solicitação de autenticação. Consulte a seção a seguir para ver detalhes sobre como usar o comando gcloud anthos auth login.

Como autenticar com clusters

Esta seção é destinada a desenvolvedores.

Agora que a CLI gcloud está instalada na máquina e o arquivo de configuração de autenticação foi fornecido pelo administrador, use a CLI gcloud ou o Console do Google Cloud para fazer a autenticação com os clusters.

Como autenticar por meio da CLI gcloud

Execute os comandos gcloud para autenticar com os clusters:

  1. Execute o comando gcloud anthos auth login para iniciar o fluxo de autenticação:

    gcloud anthos auth login \
 --cluster [CLUSTER_NAME] \
 --user [USER_NAME] \
 --login-config [AUTH_CONFIG_FILE_PATH] \
 --login-config-cert [CA_CERT_PEM_FILE] \
 --kubeconfig [CLUSTER_KUBECONFIG]

    onde:

    • [CLUSTER_NAME] (opcional) especifica o nome do cluster. Se essa sinalização for omitida, você será solicitado a escolher entre os clusters especificados no arquivo de configuração de autenticação.

    • [USER_NAME] (opcional) especifica o nome de usuário das credenciais armazenadas no arquivo kubeconfig. O valor padrão é [CLUSTER_NAME]-anthos-default-user.

    • [AUTH_CONFIG_FILE_PATH] opcional: especifica o caminho ou URL personalizado em que arquivo de configuração de autenticação é armazenado ou hospedado. É possível omitir esse parâmetro se o arquivo estiver no local padrão. Exemplo: --login-config /path/to/custom/authentication-config.yaml;

    • [CA_CERT_PEM_FILE] (opcional) especifica o caminho para um arquivo de certificado PEM da CA. Se o arquivo de configuração de autenticação estiver hospedado com segurança, é possível usar uma conexão HTTPS para acessar o arquivo. Exemplo: --login-config-cert my-cert.pem

    • [CLUSTER_KUBECONFIG] (opcional) especifica o caminho personalizado para o arquivo kubeconfig do cluster. Os tokens de ID OIDC retornados pelo seu provedor OpenID são armazenados no arquivo kubeconfig.

      Use essa sinalização se o arquivo kubeconfig estiver em um local diferente do padrão. Se essa sinalização for omitida, um novo arquivo kubeconfig será criado no local padrão. Exemplo: --kubeconfig /path/to/custom.kubeconfig

    Exemplos:

    • Autentique-se em um cluster específico:

      gcloud anthos auth login --cluster my-production-cluster

    • Use um prompt para selecionar o cluster a ser autenticado:

      gcloud anthos auth login

      Resultado:

      Please use the --cluster flag to specify a cluster from the list below:
Source: $HOME/.config/google/anthos/kubectl-anthos-config.yaml
1. Cluster: test-cluster ServerIP: https://192.168.0.1:6443
2. Cluster: test-cluster-2 ServerIP: https://192.168.0.2:6443
3. Cluster: my-production-cluster ServerIP: https://192.168.0.3:6443

    • Use um arquivo de configuração de autenticação hospedada:

      gcloud anthos auth login \
 --cluster my-production-cluster \
 --login-config HTTPS://my-secure-server/kubectl-anthos-config.yaml \
 --login-config-cert my-cert.pem

  2. Digite suas credenciais na tela de consentimento baseada no navegador que é aberta.

  3. Verifique se a autenticação foi bem-sucedida. Basta executar um dos comandos kubectl para recuperar detalhes sobre o cluster. Exemplo:

    kubectl get nodes --kubeconfig [CLUSTER_KUBECONFIG]

Resultado: o arquivo kubeconfig agora contém um token de ID que os comandos kubectl usarão para autenticar com o servidor da API Kubernetes no cluster.

Como usar SSH para autenticação em uma máquina remota

Suponha que você queira usar SSH em uma máquina remota e utilizá-la para fazer a autenticação em um cluster. Para isso, é necessário que o arquivo de configuração de autenticação esteja na máquina remota, e você precisa conseguir acessar seu provedor Open ID da máquina local.

Na máquina local, execute o comando a seguir:

ssh [USER_NAME]@[REMOTE_MACHINE] -L [LOCAL_PORT]:localhost:[REMOTE_PORT]

em que:

  • [USER_NAME] e [REMOTE_MACHINE] são os valores padrão usados para fazer login com SSH;

  • [LOCAL_PORT] é uma porta aberta de sua escolha na máquina local que você usará para acessar a máquina remota;

  • [REMOTE_PORT] é a porta que você configurou para o URL de redirecionamento OIDC. Acesse o campo kubectlRedirectURI do arquivo de configuração de autenticação.

No shell SSH, execute o comando a seguir para iniciar a autenticação:

gcloud anthos auth login --login-config [AUTH_CONFIG_FILE]

[AUTH_CONFIG_FILE] é o caminho do arquivo de configuração de autenticação na máquina remota.

Na máquina local, em um navegador, acesse http://localhost:[LOCAL_PORT]/login e conclua o fluxo de login do OIDC.

Agora, o arquivo kubeconfig na sua máquina remota tem o token necessário para acessar o cluster.

No shell SSH, verifique se você tem acesso ao cluster:

kubectl --kubeconfig [CLUSTER_KUBECONFIG] get nodes

Como autenticar usando o console do Google Cloud

Inicie o fluxo de autenticação na página de clusters do Kubernetes no Console do Google Cloud:

  1. Abra o Console do Google Cloud:

    Acessar a página de clusters do Kubernetes

  2. Localize seu cluster do Anthos em Bare Metal na lista e clique em Login.

  3. Selecione Autenticar com o provedor de identidade configurado para o cluster e clique em LOGIN.

    Você será redirecionado para o provedor de identidade, em que talvez seja necessário fazer login ou consentir para que o console do Google Cloud acesse sua conta. Depois, você verá a página Clusters do Kubernetes no console do Google Cloud.

Solução de problemas na configuração do OIDC

Analise os comportamentos e erros a seguir para resolver seus problemas de OIDC:

Configuração inválida
Se o Console do Google Cloud não conseguir ler a configuração do OIDC do cluster, o botão LOGIN será desativado.
Configuração de provedor inválida
Se a configuração do provedor de identidade for inválida, você verá uma tela de erro do provedor de identidade depois de clicar em LOGIN. Siga as instruções específicas do provedor para configurar corretamente o provedor ou o cluster.
Permissões inválidas
Se você concluir o fluxo de autenticação, mas ainda não vir os detalhes do cluster, verifique se concedeu as permissões RBAC corretas à conta usada com o OIDC. Ela pode ser uma conta diferente daquela que você usa para acessar o Console do Google Cloud.
Error: missing 'RefreshToken' field in 'OAuth2Token' in credentials struct
Pode ser que você receba esse erro se o servidor de autorização solicitar o consentimento, mas o parâmetro de autenticação necessário não tiver sido fornecido. Forneça o parâmetro prompt=consent ao campo oidc: extraparams do arquivo de configuração do Anthos em Bare Metal e gere novamente o arquivo de autenticação do cliente com a sinalização --extra-params prompt=consent.

A seguir