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

Saiba como configurar os clusters do Anthos no VMware (GKE On-Prem) para usar o OpenID Connect (OIDC) para autenticação em clusters de usuário. Esta página abrange o processo geral de configuração de provedores 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:

• Como autenticar com o OIDC e os Serviços de Federação do Active Directory (AD FS, na sigla em inglês)
• Como autenticar com o OIDC e o Google

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. 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 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.s

Antes de começar

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

  • OAuth 2.0
  • OpenID Connect
  • Escopos
  • declarações.

• 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:

• Serviços federados do Active Directory

• Google

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. É 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 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 gcloud CLI ou o console do 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 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 gcloud CLI e o console do Cloud.

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

• Estabeleça um escopo personalizado que a gcloud CLI ou o console do 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 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 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

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': ['[e-mail]', '[e-mail]']
  ...
}

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

issuerURL: 'https://server.example.com'
userClaim: 'sub'
usernamePrefix: 'uid-'
groupsClaim: '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 privilegiado aos usuários autenticados. Por exemplo, crie um ClusterRole que conceda aos usuários acesso somente leitura aos secrets do cluster e crie também 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

Observação: se seu provedor do OIDC retornar um nome de grupo que contenha caracteres duplos de barra invertida, um dos caracteres de barra invertida deverá ser omitido quando você referenciar o nome do grupo no recurso ClusterRoleBinding. Por exemplo, se você tiver criado um grupo chamado corp\\my-group, faça referência a ele no recurso ClusterRoleBinding como corp\my-group, porque o primeiro caractere de barra invertida é tratado como um caractere de escape.

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.

• Se você tiver uma versão antiga do "Plug-in do Anthos para Kubectl", desinstale esse plug-in antes de instalar a CLI gcloud e o componente anthos-auth.

• Se você tiver uma versão atual da CLI gcloud, instale a versão mais recente e 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:

Importante: o uso da CLI gcloud com clusters do Anthos no VMware não exige que você tenha uma conta do Google. Se você tiver uma conta, o login será opcional, mas não haverá necessidade de executar o comando gcloud init.

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

• Saiba mais sobre escopos e declarações.