Como fazer a autenticação com o OpenID Connect (OIDC)

Saiba como configurar o GKE On-Prem para usar um OpenID Connect (OIDC) para autenticação em clusters de usuários. Este tópico abrange o processo geral de configuração de provedores OpenID.

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

Visão geral

O GKE On-Prem é compatível com o OIDC como um dos mecanismos de autenticação para interagir com o servidor da API Kubernetes de um cluster de usuário. Com o OIDC, é possível 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:

  • 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 escolher um provedor de OpenID

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

É possível usar qualquer provedor OpenID da sua escolha. Para ver uma lista de provedores certificados, consulte Certificação OpenID.

Para os seguintes provedores OpenID, consulte as etapas específicas de configuração nos tópicos a seguir:

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

[PORT] é o número da porta.

Ao configurar seu provedor OpenID, especifique http://localhost:[PORT]/callback como um dos URLs de redirecionamento. A maneira de fazer isso depende do seu provedor.

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 seu provedor OIDC, especifique https://console.cloud.google.com/kubernetes/oidc como um dos URLs de redirecionamento. A maneira de fazer isso depende do seu provedor.

Como registrar aplicativos cliente com o provedor de OpenID

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

Antes que os desenvolvedores possam usar a CLI gcloud ou o console do Google Cloud com o provedor OpenID, você precisa registrar esses dois clientes com o provedor OpenID. O registro inclui estas etapas:

  • Descobrir o URI do emissor do provedor. É aqui que a CLI gcloud ou o console do Google Cloud envia solicitações de autenticação.

  • Forneça ao provedor o URL de redirecionamento para a CLI gcloud.

  • Forneça ao provedor o URL de redirecionamento para o Console do Google Cloud. Acesse https://console.cloud.google.com/kubernetes/oidc.

  • Estabelecer um único ID do cliente. Esse é o ID que o provedor usa para identificar a CLI gcloud e o console do Google Cloud.

  • Estabelecer uma única chave secreta do cliente. A CLI gcloud e o console do Google Cloud usam esse secret para autenticação no provedor OpenID.

  • Estabeleça um escopo personalizado que a CLI gcloud ou o console do Google Cloud podem usar para solicitar os grupos de segurança do usuário.

  • Estabeleça um nome de declaração personalizado que o provedor usará para retornar os grupos de segurança do usuário.

A execução dessas etapas depende do seu provedor OpenID.

Como preencher a especificação oidc no arquivo de configuração do GKE On-Prem

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

Antes de criar um cluster de usuário, gere um arquivo de configuração do GKE On-Prem usando gkectl create-config. A configuração inclui a especificação oidc a seguir. Preencha oidc com os valores específicos do seu provedor:

oidc:
  issuerurl:
  kubectlredirecturl:
  clientid:
  clientsecret:
  username:
  usernameprefix:
  group:
  groupprefix:
  scopes:
  extraparams:
  usehttpproxy:
  capath:
  • issuerurl: obrigatório. URL do provedor de OpenID, como "https://example.com/adfs". 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. É necessário usar HTTPS.
  • kubectlredirecturl:: obrigatório. O URL de redirecionamento que você configurou anteriormente para a CLI gcloud.
  • clientid: obrigatório. 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.
  • clientsecret: opcional. O secret do aplicativo cliente. Tanto a CLI gcloud quanto o Console do Google Cloud usam esse secret.
  • username: opcional. Declaração do JWT a ser usada como nome de usuário. O padrão é sub, que deve ser um identificador exclusivo do usuário final. É possível escolher outras declarações, como email ou name, dependendo do provedor OpenID. No entanto, declarações diferentes de email são prefixadas com o URL do emissor para evitar conflitos de nomes com outros plug-ins.
  • 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: opcional. A declaração do JWT que o provedor usará para retornar seus grupos de segurança.
  • groupprefix: opcional. Prefixo anexado para agrupar declarações e evitar conflitos com nomes atuais. Por exemplo, um grupo foobar e um prefixo gid-, gid-foobar. Por padrão, esse valor está vazio e não há prefixo.
  • scopes: opcional. Escopos extras a serem enviados ao provedor OpenID como uma lista delimitada por vírgulas.
    • Para autenticação com o Microsoft Azure ou Okta, transmita offline_access.

  • extraparams: opcional. Outros parâmetros de chave-valor a serem enviados ao provedor OpenID como uma lista delimitada por vírgulas.
  • usehttpproxy: opcional. Especifica se um proxy reverso precisa ser implantado no cluster para permitir que o Console do Google Cloud acesse o provedor OIDC local para autenticar usuários. O valor precisa ser uma string: "true" ou "false". Se o provedor de identidade não estiver acessível pela Internet pública e você quiser autenticar usando o Console do Google Cloud, esse campo precisará ser definido como "true". Se for deixado em branco, o padrão deste campo será "false".

  • capath: opcional. Caminho para o certificado da autoridade de certificação (CA, na sigla em inglês) que emitiu o certificado da Web do seu provedor de identidade. Pode ser que esse valor não seja necessário. Por exemplo, se o certificado do provedor de identidade tiver sido emitido por uma CA pública conhecida, você não precisará fornecer um valor aqui. No entanto, se usehttpproxy for "true", esse valor precisará ser fornecido, mesmo para uma CA pública conhecida.

Exemplo: como autorizar usuários e grupos

Muitos provedores codificam propriedades de identificação do usuário, como IDs de e-mail e usuário, em um token. No entanto, essas propriedades têm riscos implícitos para políticas de autenticação:

  • Os IDs do usuário podem dificultar a leitura e a auditoria das políticas.
  • Os e-mails podem criar riscos de disponibilidade (se um usuário alterar o e-mail principal) e de segurança (se um e-mail puder ser reatribuído).

Portanto, é uma prática recomendada usar políticas de grupo, já que um ID de grupo pode ser permanente e fácil de auditar.

Suponha que seu provedor crie tokens de identidade que incluam os campos a seguir:

{
  'iss': 'https://server.example.com'
  'sub': 'u98523-4509823'
  'groupList': ['developers@example.corp', 'us-east1-cluster-admins@example.corp']
  ...
}

Com esse formato de token, você preencheria a especificação oidc do arquivo de configuração da seguinte forma:

issueruri: 'https://server.example.com'
username: 'sub'
usernameprefix: 'uid-'
group: 'groupList'
groupprefix: 'gid-'
extraparams: 'resource=token-groups-claim'
...

Depois de criar o cluster de usuário, use o controle de acesso baseado em papéis (RBAC, na sigla em inglês) do Kubernetes para conceder acesso prioritário aos usuários autenticados. Por exemplo, crie um ClusterRole que conceda aos usuários acesso somente leitura aos secrets do cluster e um recurso ClusterRoleBinding para vincular o papel ao grupo autenticado:

ClusterRole

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

ClusterRoleBinding

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-secrets-admins
subjects:
  # Allows anyone in the "us-east1-cluster-admins" group to
  # read Secrets in any namespace within this cluster.
- kind: Group
  name: gid-us-east1-cluster-admins # Name is case sensitive
  apiGroup: rbac.authorization.k8s.io
  # Allows this specific user to read Secrets in any
  # namespace within this cluster
- kind: User
  name: uid-u98523-4509823
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

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]

[USER_CLUSTER_KUBECONFIG] é o caminho do arquivo kubeconfig do cluster de 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]

    em que

    • [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 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 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 o cluster do GKE On-Prem 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 GKE On-Prem e gere novamente o arquivo de autenticação do cliente com a sinalização --extra-params prompt=consent.

A seguir