Como autenticar com o OIDC e o Google

Saiba como configurar os clusters do Anthos no VMware (GKE On-Prem) para usar o OpenID Connect (OIDC) com o Google como provedor OpenID para autenticação nos clusters de usuário. Esta página aborda o processo geral para ajudar você a entender como configurar o Google como provedor OpenID.

Para uma visão geral dos clusters do Anthos no fluxo de autenticação do VMware, consulte Autenticação. Para saber como configurar o OIDC com outros provedores de OpenID, consulte os seguintes recursos:

Os clusters do Anthos no VMware 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 de usuário. 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:

  • Usar a 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: essa pessoa cria um ou mais clusters de usuário 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 Google 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

Substitua PORT pelo 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 de usuário, 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: GKE on-prem.

  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 no VMware 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 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 configurar oidc em clusters do Anthos no VMware

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

Para configurar a autenticação do OIDC, é preciso configurar o ClientConfig CRD do cluster de usuário com os detalhes da autenticação de um cluster. Para fazer isso, edite o objeto padrão do KRM do tipo clientconfig no namespace kube-public.

kubectl --kubeconfig USER_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. A configuração inclui a seguinte especificação do OIDC:

authentication:
  - name: NAME_STRING
    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 como preencher os campos do objeto oidc do CRConfig do ClientConfig. Para informações gerais sobre o objeto CRD oidc do ClientConfig, consulte Como configurar o OIDC em clusters do Anthos no VMware.

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==

Esse valor é opcional nas versões 1.4 e 1.5. Esse valor é opcional na versão 1.6.1 e posteriores. No entanto, esse valor é obrigatório na versão 1.6.0. Isso é particularmente importante para os upgrades de 1,5 a 1.6.0. Para mais informações, consulte Problemas conhecidos nas notas do lançamento 1.6.0.

 String
clientID Sim O ID do aplicativo cliente que faz solicitações de autenticação para o 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. String
clientSecret Não O secret do 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. String
parâmetros extras Não Defina como "prompt=consent,access_type=offline".

Lista delimitada por vírgulas
groupsClaim Não Deixe em branco. String
groupPrefix Não Deixe em branco. String
issuerURI Sim 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. String do URL
kubectlRedirectURI Sim O URL de redirecionamento que você configurou anteriormente para a CLI gcloud. String do URL
scopes Sim Outros escopos a serem enviados ao provedor OpenID. Defina como "email". Lista delimitada por vírgulas
userClaim Não Defina como "email". String
userPrefix Não 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. 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

Como criar uma política de RBAC para o cluster de usuário

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 aos recursos em todo o cluster, 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 [USER_CLUSTER_KUBECONFIG] apply -f secret-viewer-cluster-role.yaml

em que [USER_CLUSTR_KUBECONFIG] é o arquivo kubeconfig do cluster de usuário.

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

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

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 de usuário, 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 gkectl:

gkectl create-login-config --kubeconfig USER_CLUSTER_KUBECONFIG

Substitua USER_CLUSTER_KUBECONFIG pelo caminho do arquivo kubeconfig do cluster do usuário. Quando você executou gkectl create cluster para criar o cluster de usuário, 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 de usuário em um arquivo de configuração de autenticação atual. Nesse arquivo, é possível mesclar ou combinar outros detalhes de autenticação de cluster de usuário:

  • Mesclar outros detalhes de autenticação de cluster de usuário no arquivo de configuração atual.
  • Combinar os outros detalhes de autenticação do cluster de usuários 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 de usuários 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 gkectl a seguir para mesclar ou combinar detalhes de configuração:

    gkectl create-login-config --kubeconfig USER_CLUSTER_KUBECONFIG \
--merge-from IN_AUTH_CONFIG_FILE --output OUT_AUTH_CONFIG_FILE

    Substitua:

    • USER_CLUSTER_KUBECONFIG especifica o arquivo kubeconfig do cluster de usuário 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 existente.
      • 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 de usuários, 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 instalar a CLI gcloud

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

Cada desenvolvedor ou usuário que precisa se autenticar com um cluster precisa 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 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 de usuário

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 USER_CLUSTER_KUBECONFIG

    em que:

    • CLUSTER_NAME (opcional) especifica o nome do cluster de usuário. Se essa sinalização for omitida, você será solicitado a escolher entre os clusters de usuário 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;

    • USER_CLUSTER_KUBECONFIG (opcional) especifica o caminho personalizado para o arquivo kubeconfig do cluster de usuário. 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 USER_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 de usuário.

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 de usuário. 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 de usuário.

No shell SSH, verifique se você tem acesso ao cluster de usuário:

kubectl --kubeconfig USER_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 seus clusters do Anthos no cluster do VMware na lista e clique em Fazer 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, onde talvez seja necessário fazer login ou consentir para que o Console do Google Cloud acesse sua conta. Depois, voltará para 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 aos clusters do Anthos no campo oidc: extraparams do arquivo de configuração da VMware e gere novamente o arquivo de autenticação de cliente com a sinalização --extra-params prompt=consent.

A seguir