Autenticação com o OIDC e AD FS

Saiba como configurar os clusters do Anthos no VMware (GKE On-Prem) para usar o OpenID Connect (OIDC) com os Serviços de Federação do Active Directory (AD FS, na sigla em inglês) para a autenticação nos clusters de usuários. Nesta página, abordamos o processo em geral para ajudar você a entender como configurar um servidor AD FS como seu provedor de OpenID com o Active Directory como o banco de dados do usuário.

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:

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

  • Você precisa ter um servidor do AD FS e um banco de dados de usuários do Active Directory para concluir as etapas desta seção.

  • O OIDC é compatível apenas com o AD FS versão 2016 e mais recentes.

  • Conheça os seguintes comportamentos no AD FS:

    • Nas versões do AD FS anteriores à 5.0, o atributo LDAP Token-Groups Qualified Names no seu banco de dados do Active Directory é mapeado para a declaração groups. Na versão 5.0 e mais recentes, o atributo é Token-Groups Qualified by Domain name.

    • O servidor do AD FS retorna tokens que incluem o ID do usuário, o ID do emissor, a declaração openid e a declaração groups. A declaração groups (Group na versão 5.0) lista os grupos de segurança aos quais o usuário pertence.

  • 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 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 seu número de porta.

Ao configurar o servidor do AD FS, especifique http://localhost:PORT/callback como um dos seus URLs de redirecionamento.

URL de redirecionamento do Console do Cloud

O URL de redirecionamento do Console do Cloud é:

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

Ao configurar o servidor do AD FS, especifique https://console.cloud.google.com/kubernetes/oidc como um dos seus URLs de redirecionamento.

Como configurar o AD FS

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

Use um conjunto de assistentes de gerenciamento do AD FS para configurar o servidor do AD FS e o banco de dados de usuários do Active Directory:

  1. Abra o painel de gerenciamento do AD FS.

  2. Selecione Grupos de aplicativos, > Ações > Adicionar um grupo de aplicativos.

  3. Selecione Aplicativo do servidor. Insira um nome e uma descrição de sua escolha. Clique em Próximo.

  4. Insira os dois URLs de redirecionamento. Você recebe um ID de cliente. É assim que o servidor do AD FS identifica a CLI gcloud e o Console do Cloud. Salve o ID do cliente para uso posterior.

  5. Selecione Gerar um secret compartilhado. A CLI gcloud e o Console do Cloud usam esse secret para autenticar no servidor AD FS. Guarde o secret para mais tarde.

Como configurar grupos de segurança (opcional)

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

  1. No gerenciamento do AD FS, selecione Confiança de terceira parte confiável > Adicionar uma nova confiança de terceira parte confiável.

  2. Selecione Reconhecimento de declarações e clique em Iniciar.

  3. Selecione Inserir dados sobre terceiros confiáveis manualmente.

  4. Insira um nome de exibição.

  5. Pule os próximos dois passos.

  6. Insira um identificador de confiança da parte confiável. Sugestão: token-groups-claim.

  7. Em Política de controle de acesso, selecione Permitir todos. Isso significa que todos os usuários compartilham as respectivas informações de grupo de segurança com a CLI gcloud e o Console do Cloud.

  8. Clique em Concluir.

Como mapear atributos LDAP para nomes de declaração

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

  1. No gerenciamento do AD FS, selecione Confiança de terceira parte confiável > Editar política de emissão de declarações.

  2. Selecione Enviar atributos LDAP como declarações e clique em Próximo.

  3. Em Nome da regra de declaração, insira groups.

  4. Em Armazenamento de atributos, selecione Active Directory.

  5. Na tabela, em Atributo LDAP, selecione:

    • AD FS versão 5.0 e mais recentes: Grupos de token qualificados pelo nome de domínio
    • Versões do AD FS anteriores à 5.0: Nomes qualificados de grupos de token

  6. Em Tipo de declaração de saída, selecione:

    • AD FS versão 5.0 e mais recentes: Grupo
    • Versões do AD FS anteriores à 5.0: grupos

  7. Clique em Concluir e em Aplicar.

Como registrar a CLI e o Console do Cloud com o AD FS

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

Abra uma janela do PowerShell no modo de administrador e digite este comando:

Grant-AdfsApplicationPermission `
     -ClientRoleIdentifier "CLIENT_ID" `
     -ServerRoleIdentifier SERVER_ROLE_IDENTIFIER `
     -ScopeName "allatclaims", "openid"

Substitua:

  • CLIENT_ID é o ID do cliente que você recebeu anteriormente;

  • SERVER_ROLE_IDENTIFIER é o identificador de declaração que você inseriu anteriormente; o identificador sugerido era token-groups-claim

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 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: "https://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
cloudConsoleRedirectURI Sim O URL de redirecionamento que Cloud console usa para autorização. O valor deve ser https://console.cloud.google.com/kubernetes/oidc. String do URL
kubectlRedirectURI Sim O URL de redirecionamento que kubectl usa para autorização. String do URL
scopes Sim Outros escopos a serem enviados ao provedor OpenID. O Microsoft Azure e o Okta exigem o escopo offline_access. Lista delimitada por vírgulas
userClaim Sim Declaração do JWT a ser usada como nome de usuário. É possível escolher outras declarações, como e-mail ou nome, dependendo do provedor OpenID. No entanto, as declarações diferentes de e-mail são prefixadas com o URL do emissor para evitar conflitos de nomenclatura. String
userPrefix Não Prefixo anexado a declarações de nome de usuário para evitar conflitos com nomes atuais. Se você não fornecer esse campo e userClaim 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

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']
  ...
}

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

issuerURL: '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 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

Observe que o servidor da API Kubernetes considera uma barra invertida como um caractere de escape. Portanto, se o nome do usuário ou grupo contiver uma barra invertida dupla (\\), o servidor da API a lerá como uma \ única ao analisar o valor do campo. Para garantir que o servidor da API interprete corretamente um \\ em um campo de texto, você precisa substituí-lo por \\\\. Por exemplo, o servidor da API Kubernetes analisará

"unique_name": "EXAMPLE\\\\cluster-developer" como

"unique_name": "EXAMPLE\\cluster-developer"

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

  1. Abra o Console do 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 Cloud acesse sua conta. Depois, irá para a página Clusters do Kubernetes no console do 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 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 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