Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Faça login usando um nome de domínio totalmente qualificado (FQDN)
O serviço de identidade do GKE permite que você faça login em clusters configurados a partir da linha de comando usando um nome de usuário e senha de um provedor de identidade de terceiros. Siga as instruções nesta página se o administrador do cluster tiver optado por permitir a autenticação diretamente no servidor do serviço de identidade do GKE com um nome de domínio totalmente qualificado (FQDN).
Para provedores SAML, o acesso de login é compatível apenas com essa abordagem de
autenticação.
Essa abordagem de autenticação é compatível apenas com clusters locais (Google Distributed Cloud) em VMware e bare metal, a partir da versão 1.29. Outros tipos de cluster não são suportados.
É preciso ter pelo menos a versão 477.0.0 da
CLI gcloud para fazer login com o FQDN fornecido.
Fluxo de trabalho de login
Aqui estão as etapas do fluxo de trabalho quando um usuário faz login usando a abordagem de acesso FQDN:
Iniciar login: o usuário executa o comando gcloud anthos auth login --server APISERVER-URL para iniciar o processo de login.
Seleção de provedor de identidade: o usuário recebe uma lista de provedores de identidade configurados. O usuário seleciona o provedor onde suas credenciais são armazenadas.
Autenticação com provedor de identidade: o processo de autenticação difere com base no protocolo do provedor de identidade escolhido:
OIDC: o usuário é redirecionado para a página de login do provedor OIDC. Após um login bem-sucedido, o provedor envia um código de volta ao serviço de identidade do GKE, que o troca por um token de acesso por meio de uma comunicação de canal traseiro.
SAML: o usuário é redirecionado para a página de login do provedor SAML. Após um
login bem-sucedido, o provedor envia diretamente um token (declaração) de volta ao serviço de identidade do GKE,
evitando um callback extra.
LDAP: em vez de redirecionar para um provedor externo, o serviço de identidade do GKE exibe uma página de login em que o usuário insere as credenciais LDAP, que é verificada diretamente com o servidor LDAP.
Verificação de token e geração de arquivo kubeconfig: o serviço de identidade do GKE verifica o token recebido (ou declaração), cria um novo token para o usuário e envia de volta um arquivo kubeconfig contendo esse token.
Acesso ao cluster: o usuário pode acessar o cluster usando comandos kubectl.
O cliente kubectl envia automaticamente o token do arquivo kubeconfig com cada solicitação.
Validação de token e autorização RBAC: o servidor da API Kubernetes recebe o token, o serviço de identidade do GKE verifica esse token e recupera as declarações do usuário (nome de usuário e grupos).
Após a validação bem-sucedida, o servidor API executa verificações de controle de acesso baseado em função (RBAC) para determinar os recursos que o usuário está autorizado a acessar.
Faça login usando certificados SNI confiáveis
Os certificados SNI simplificam o acesso ao cluster aproveitando os certificados confiáveis
já presentes em dispositivos corporativos. Os administradores podem especificar este certificado no momento da criação do cluster. Se o seu cluster usar um certificado SNI confiável no nível do cluster, use o comando nesta seção com o FQDN fornecido pelo seu administrador para fazer login no cluster e receber um token de acesso. Você também pode usar um arquivo kubeconfig seguro onde o token é armazenado após a autenticação bem-sucedida.
Execute o seguinte comando para autenticar no servidor:
APISERVER-URL: FQDN do servidor da API Kubernetes do cluster.
OUTPUT_FILE: use essa sinalização se o arquivo kubeconfig estiver em um local diferente do padrão. Se essa sinalização for omitida, os tokens de autenticação serão adicionados ao arquivo kubeconfig no local padrão. Por exemplo:
--kubeconfig /path/to/custom.kubeconfig.
Fazer login usando certificados emitidos pela AC do cluster
Se você não usar um certificado SNI confiável no nível do cluster,
o certificado usado pelo serviço de identidade será emitido pela autoridade
certificadora (AC) do cluster. Os administradores distribuem esse certificado de CA para os usuários.
Execute o seguinte comando usando o certificado de CA do cluster para fazer login no cluster:
A autenticação entre dispositivos permite fazer login em clusters do Google Distributed Cloud (GDC) em dispositivos que não têm um navegador instalado. Você pode iniciar o processo de autenticação no dispositivo principal (que não tem um navegador instalado) e concluí-lo em um dispositivo secundário com um navegador instalado.
Siga as etapas abaixo para configurar a autenticação entre dispositivos.
Fazer login no dispositivo principal
Execute o comando a seguir para autenticar-se no servidor usando o dispositivo principal.
Especifique o argumento --no-browser para indicar que o dispositivo usado para
acessar o cluster não tem um navegador instalado.
O serviço de identidade do GKE retorna um comando que precisa ser usado ao fazer login
no segundo dispositivo. Este é um exemplo do comando:
You are authorizing gcloud CLI without access to a web browser. Please run the following command on a machine with a web browser and copy its output back here.
gcloud auth login --server APISERVER-URL --kubeconfig OUTPUT_FILE --remote-bootstrap="URL_TO_COPY_ON_THE_SECOND_DEVICE"
Enter the output of the above command:
Copie o comando gcloud.
Fazer login nos clusters usando o segundo dispositivo
Antes de fazer login no segundo dispositivo, verifique se o navegador está instalado
e se há conectividade de rede com o servidor da API Kubernetes. Execute o comando copiado da
etapa anterior no segundo dispositivo.
Ao tentar fazer login nesse dispositivo, uma mensagem de alerta será exibida. Siga o processo de autenticação padrão conforme ele é exibido no navegador. Depois da autenticação, você vai receber um código único. Copie esse código.
WARNING: The following line enables access to your Cluster resources. ONLY COPY IT TO A MACHINE YOU TRUST AND RUN 'gcloud auth login --server APISERVER-URL --kubeconfig OUTPUT_FILE --no-browser' EARLY ON.
Or_mHYQFm90efgJdwhajx0KeC_WXkuvBPuWv_83nFX9J_Eawm3tQcBpxBBWszj6Ix8dAWCgc1QjJBrlt67bzIYIBTexU7dc_ggtkMTNkG7wCIGYZ75zfg9P1gBshP33STe0ks-AoVonzk01YekMbyNugeYSO18CBwFhaDDSMABq4PI-clgbaSh8CPqrvDKRLenbvfD9BSK6SW945I0bOgPURxNzUX4sICWcvFozhQdLYICuwRM0AgarNFwoeh-0wbJGyRqUjq2NJbaYdf-VCaByiZaGPR2B1QVGXO7deKGtUnk1_tTFOnB6sJQvT6UJ8Ge5nkR38rqBeeGkYdlVIBTXShENG80An1Ve524xZupSzCHNSVTJqYg
Concluir o login no dispositivo principal
Cole o código copiado da etapa anterior no prompt do dispositivo
principal.
Enter the code you received on the other device: Or_mHYQFm90efgJdwhajx0KeC_WXkuvBPuWv_83nFX9J_Eawm3tQcBpxBBWszj6Ix8dAWCgc1QjJBrlt67bzIYIBTexU7dc_ggtkMTNkG7wCIGYZ75zfg9P1gBshP33STe0ks-AoVonzk01YekMbyNugeYSO18CBwFhaDDSMABq4PI-clgbaSh8CPqrvDKRLenbvfD9BSK6SW945I0bOgPURxNzUX4sICWcvFozhQdLYICuwRM0AgarNFwoeh-0wbJGyRqUjq2NJbaYdf-VCaByiZaGPR2B1QVGXO7deKGtUnk1_tTFOnB6sJQvT6UJ8Ge5nkR38rqBeeGkYdlVIBTXShENG80An1Ve524xZupSzCHNSVTJqYg
O dispositivo usa esse código para gerar uma credencial que é salva em um
arquivo kubeconfig. Esse arquivo permite o acesso ao cluster no dispositivo
principal. Ao fazer login, a seguinte mensagem será exibida:
You are logged in!
Context is stored under the name '{cluster-name}'
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-09-04 UTC."],[],[],null,["# Log in using a fully qualified domain name (FQDN)\n=================================================\n\nGKE Identity Service lets you log in to configured clusters from the command line using a username and password from a third party identity provider. Follow the instructions in this page if your cluster administrator has chosen to let you authenticate directly on the GKE Identity Service server with a fully qualified domain name (FQDN).\nFor SAML providers, login access is supported only through this authentication\napproach.\n\nThis authentication approach is supported only for on-prem clusters (Google Distributed Cloud) on VMware\nand bare metal, from version 1.29. Other cluster types are not supported.\n\nThe `gcloud` CLI version required to log in with your provided FQDN is\natleast version 477.0.0.\n\nLogin workflow\n--------------\n\nHere are the workflow steps when a user logs in using the FQDN access approach:\n\n1. **Initiate login** : The user runs the command `gcloud anthos auth login --server `\u003cvar translate=\"no\"\u003eAPISERVER-URL\u003c/var\u003e to initiate the login process.\n2. **Identity provider selection**: The user is given a list of configured identity providers. The user selects the provider where their credentials are stored.\n3. **Authentication with identity provider:** The authentication process differs based on the identity provider protocol you choose:\n\n - **OIDC**: The user is redirected to the OIDC-provider login page. After a successful login, the provider sends a code back to the GKE Identity Service, which exchanges it for an access token through a back-channel communication.\n - **SAML**: The user is redirected to the SAML-provider login page. After a successful login, the provider directly sends a token (assertion) back to the GKE Identity Service thereby avoiding an additional callback.\n - **LDAP**: Instead of redirecting to an external provider, the GKE Identity Service displays a login page where the user enters their LDAP credentials, which is verified directly with the LDAP server.\n4. **Token verification and kubeconfig file generation**: The GKE Identity Service\n verifies the token received (or assertion), creates a new token for the user, and\n sends back a kubeconfig file containing this token.\n\n5. **Cluster access** : The user can access the cluster using `kubectl` commands.\n The `kubectl` client automatically sends the token from the kubeconfig file with\n each request.\n\n6. **Token validation and RBAC authorization**: The Kubernetes API server receives\n the token, GKE Identity Service verifies this token, and retrieves the user's claims (username and groups).\n After successful validation, the API server runs Role-Based Access Control (RBAC)\n checks to determine the resources that the user is authorized to access.\n\nLog in using trusted SNI certificates\n-------------------------------------\n\nSNI certificates simplify cluster access by leveraging trusted certificates\nalready present on corporate devices. Administrators can specify this certificate at the\ntime of cluster creation. If your cluster uses a trusted SNI certificate at the cluster\nlevel, use the command in this section with the FQDN provided by your\nadministrator to log in to the cluster and receive an access token. You can also\nuse a secure `kubeconfig` file where the token is stored after successful authentication.\n\nRun the following command to authenticate to the server:\n\n`gcloud anthos auth login --server `\u003cvar translate=\"no\"\u003eAPISERVER-URL\u003c/var\u003e` --kubeconfig `\u003cvar translate=\"no\"\u003eOUTPUT_FILE\u003c/var\u003e\n\nReplace the following:\n\n- \u003cvar translate=\"no\"\u003eAPISERVER-URL\u003c/var\u003e: FQDN of the cluster's Kubernetes API server.\n- \u003cvar translate=\"no\"\u003eOUTPUT_FILE\u003c/var\u003e: Use this flag if your `kubeconfig` file resides in a location other than the default. If this flag is omitted, authentication tokens are added to the `kubeconfig` file in the default location. For example: `--kubeconfig /path/to/custom.kubeconfig`.\n\nLog in using cluster CA-issued certificates\n-------------------------------------------\n\nIf you don't use a trusted SNI certificate at the cluster level, then\nthe certificate used by the identity service is issued by the cluster's\ncertificate authority (CA). Administrators distribute this CA certificate to users.\nRun the following command using the cluster's CA certificate to log in to your cluster:\n\n`gcloud anthos auth login --server `\u003cvar translate=\"no\"\u003eAPISERVER-URL\u003c/var\u003e` --kubeconfig `\u003cvar translate=\"no\"\u003eOUTPUT_FILE\u003c/var\u003e` --login-config-cert `\u003cvar translate=\"no\"\u003eCLUSTER_CA_CERTIFICATE\u003c/var\u003e\n| **Note:** As a recommendation, users can trust the CA certificate on their devices and browsers by following the device-specific instructions. This is a one-time activity. Once the CA certificate is trusted, you can log in to the cluster without specifying the `--login-config-cert` argument in the command.\n\nCross-device authentication\n---------------------------\n\nCross-device authentication lets you sign in to Google Distributed Cloud (GDC) clusters from devices that don't have a browser installed. You can initiate the authentication process on your primary device (which doesn't have a browser installed) and complete it on a secondary device installed with a browser.\n\nUse the following steps for a cross-device authentication setup.\n\n1. **Log in to your primary device**\n\n Run the following command to authenticate to the server on your primary device.\n Specify the argument `--no-browser` to indicate that the device you need to\n access your cluster from does not have a browser installed.\n\n `gcloud anthos auth login --server `\u003cvar translate=\"no\"\u003eAPISERVER-URL\u003c/var\u003e` --kubeconfig `\u003cvar translate=\"no\"\u003eOUTPUT_FILE\u003c/var\u003e` --no-browser`\n\n GKE Identity Service returns a command that you need to use when you log\n in from the second device. Here's an example of what the command looks like: \n\n You are authorizing gcloud CLI without access to a web browser. Please run the following command on a machine with a web browser and copy its output back here.\n\n gcloud auth login --server \u003cvar translate=\"no\"\u003eAPISERVER-URL\u003c/var\u003e --kubeconfig \u003cvar translate=\"no\"\u003eOUTPUT_FILE\u003c/var\u003e --remote-bootstrap=\"\u003cvar translate=\"no\"\u003eURL_TO_COPY_ON_THE_SECOND_DEVICE\u003c/var\u003e\"\n\n Enter the output of the above command:\n\n Copy the `gcloud` command.\n2. **Log in to clusters on the second device**\n\n Before logging in from the second device, verify that you have the browser installed\n and have network connectivity to the Kubernetes API server. Run the command you copied from\n the previous step on the second device. \n\n gcloud auth login --server \u003cvar translate=\"no\"\u003eAPISERVER-URL\u003c/var\u003e --kubeconfig \u003cvar translate=\"no\"\u003eOUTPUT_FILE\u003c/var\u003e --remote-bootstrap=\"\u003cvar translate=\"no\"\u003eURL_TO_COPY_ON_THE_SECOND_DEVICE\u003c/var\u003e\"\n\n When attempting to log in from this device, a warning message is displayed. Follow the standard authentication process as displayed on the browser. After a successful authentication, you will be provided with a one-time code. Copy this code. \n\n WARNING: The following line enables access to your Cluster resources. ONLY COPY IT TO A MACHINE YOU TRUST AND RUN 'gcloud auth login --server \u003cvar translate=\"no\"\u003eAPISERVER-URL\u003c/var\u003e --kubeconfig \u003cvar translate=\"no\"\u003eOUTPUT_FILE\u003c/var\u003e --no-browser' EARLY ON.\n\n Or_mHYQFm90efgJdwhajx0KeC_WXkuvBPuWv_83nFX9J_Eawm3tQcBpxBBWszj6Ix8dAWCgc1QjJBrlt67bzIYIBTexU7dc_ggtkMTNkG7wCIGYZ75zfg9P1gBshP33STe0ks-AoVonzk01YekMbyNugeYSO18CBwFhaDDSMABq4PI-clgbaSh8CPqrvDKRLenbvfD9BSK6SW945I0bOgPURxNzUX4sICWcvFozhQdLYICuwRM0AgarNFwoeh-0wbJGyRqUjq2NJbaYdf-VCaByiZaGPR2B1QVGXO7deKGtUnk1_tTFOnB6sJQvT6UJ8Ge5nkR38rqBeeGkYdlVIBTXShENG80An1Ve524xZupSzCHNSVTJqYg\n\n3. **Complete log in on your primary device**\n\n Paste the copied code from the previous step into the prompt of your primary\n device. \n\n Enter the code you received on the other device: Or_mHYQFm90efgJdwhajx0KeC_WXkuvBPuWv_83nFX9J_Eawm3tQcBpxBBWszj6Ix8dAWCgc1QjJBrlt67bzIYIBTexU7dc_ggtkMTNkG7wCIGYZ75zfg9P1gBshP33STe0ks-AoVonzk01YekMbyNugeYSO18CBwFhaDDSMABq4PI-clgbaSh8CPqrvDKRLenbvfD9BSK6SW945I0bOgPURxNzUX4sICWcvFozhQdLYICuwRM0AgarNFwoeh-0wbJGyRqUjq2NJbaYdf-VCaByiZaGPR2B1QVGXO7deKGtUnk1_tTFOnB6sJQvT6UJ8Ge5nkR38rqBeeGkYdlVIBTXShENG80An1Ve524xZupSzCHNSVTJqYg\n\n Your device uses this code to generate a credential that is saved in a\n `kubeconfig` file. This file enables access to the cluster on your primary\n device. When you have logged in, the following message is displayed: \n\n You are logged in!\n Context is stored under the name '{cluster-name}'"]]
