Login

Esta página aborda como acessar e gerenciar cargas de trabalho e recursos no Google Distributed Cloud (GDC) com isolamento físico. Ela descreve como autenticar, gerar arquivos kubeconfig para recursos zonais e globais e gerenciar a inatividade da sessão. Entender esses processos garante acesso seguro e confiável aos seus projetos e cargas de trabalho.

Esta página é destinada a públicos-alvo do grupo de administradores de plataforma (como administradores de TI) ou do grupo de operadores de aplicativos (como desenvolvedores de aplicativos) que querem usar recursos do GDC. Para mais informações, consulte Públicos-alvo da documentação do GDC com isolamento físico.

É possível acessar cargas de trabalho usando o console do GDC, a CLI gdcloud ou a CLI kubectl.

Autenticar sua conta para acesso

Para fazer login no console do GDC ou em um cluster, siga estas etapas:

Console

Abra o URL a seguir em uma nova guia do navegador para acessar a interface do usuário (UI) do Distributed Cloud:

https://GDC_URL

Substitua GDC_URL pelo nome de domínio que você usa para acessar o Distributed Cloud fornecido pelo operador de infraestrutura (IO). Ao abrir qualquer URL pela primeira vez, o Distributed Cloud redireciona você para a página de login do provedor de identidade se o operador de infraestrutura (IO) tiver configurado a página.

Por exemplo, a imagem a seguir faz login na UI do console de uma organização chamada org-1:

CLI

Ao fazer login na CLI gdcloud, use o gdcloud auth login comando para autenticar um principal na CLI gdcloud. A CLI gdcloud usa esse principal para autenticação e autorização ao gerenciar Google Cloud recursos e serviços.

Antes de fazer login, faça o seguinte:

• Faça o download do binário da CLI gdcloud e instale-o no seu sistema. Para mais informações, consulte Fazer o download da CLI gdcloud.
• Configure e inicialize a configuração padrão da CLI gdcloud. Defina o URL correto da organização, que é usado para buscar o endpoint de configuração de login. Para mais informações, consulte Instalação da CLI gdcloud.
• Instale o plug-in de autenticação gdcloud-k8s-auth-plugin. Para mais informações, consulte Autenticação da CLI gdcloud.

Importante: execute as próximas etapas no seu sistema com sua conta de usuário e não com a conta raiz. A CLI gdcloud não abre um navegador automaticamente no modo raiz.

Para fazer login em um servidor da API Management ou em um cluster do Kubernetes, siga estas etapas:

• Servidor da API Management:

1. Exporte o caminho em que você quer armazenar o arquivo kubeconfig do servidor da API Management:

   export KUBECONFIG=MANAGEMENT_API_SERVER
   

   Substitua MANAGEMENT_API_SERVER pelo caminho para o diretório em que o arquivo kubeconfig será armazenado.

2. Autentique sua instância da CLI gdcloud para fazer login. Há duas maneiras de autenticar:

   • Login padrão do navegador:use esse fluxo de autenticação ao fazer login em um navegador.

     gdcloud auth login
     

   • Login do dispositivo secundário:use esse fluxo de autenticação se o dispositivo principal não tiver um navegador disponível. Esse fluxo inicia o login no dispositivo principal sem acesso ao navegador e continua o login com o dispositivo secundário que tem acesso ao navegador.

     Inicie o login no dispositivo principal sem navegador:

     gdcloud auth login --no-browser
     

     A variável de ambiente KUBECONFIG é atualizada com os arquivos kubeconfig de todos os servidores e clusters de API na organização. Se a variável KUBECONFIG não estiver definida, a CLI kubectl usará o arquivo kubeconfig padrão armazenado em $HOME/.kube/config.

     Para pular a edição dos arquivos kubeconfig, adicione a flag --skip-kubeconfig-update ao comando. Exemplo:

     gdcloud auth login --no-browser --skip-kubeconfig-update
     

     Copie a resposta ao comando da CLI gdcloud que é impressa e execute-a em uma máquina com acesso ao navegador.

3. Siga as instruções na página da Web para concluir o processo de login.

   Quando o login for concluído, o navegador vai mostrar a mensagem Autenticação bem-sucedida. Feche esta janela.

4. Siga as instruções no terminal. Quando o login for concluído, o terminal vai mostrar a mensagem: Você fez login.

   Observação: Se você receber um erro x509: certificate signed by unknown authority, sua estação de trabalho não confia no certificado de CA usado no GDC. Siga o procedimento da sua organização para verificar o repositório de certificação confiável da sua estação de trabalho.
   Aviso: usar --login-config-cert com um certificado não verificado deixa você vulnerável a ataques man-in-the-middle. Confie apenas no repositório de confiança da sua estação de trabalho em vez de confiar em um certificado de CA de fontes desconhecidas.

• Cluster do Kubernetes:

1. Autentique sua instância da CLI gdcloud para fazer login. Há duas maneiras de autenticar:

   • Login padrão do navegador:use esse fluxo de autenticação ao fazer login em um navegador.

     gdcloud auth login
     

   • Login do dispositivo secundário:use esse fluxo de autenticação se o dispositivo principal não tiver um navegador disponível. Esse fluxo inicia o login no dispositivo principal sem acesso ao navegador e continua o login com o dispositivo secundário que tem acesso ao navegador.

     1. Inicie o login no dispositivo principal sem navegador:

        gdcloud auth login --no-browser
        

        O comando no dispositivo principal imprime outro comando gdcloud que você precisa executar no dispositivo secundário na etapa c.

     2. Repita a etapa 1 para fazer o download do certificado no dispositivo secundário.

     3. Conclua o login no dispositivo secundário inserindo o comando impresso no dispositivo principal na etapa a.

   Essa ação abre um navegador para fazer login no provedor de identidade (IdP) configurado. Informe o usuário e a senha definidos durante a configuração inicial da CLI gdcloud para fazer login.

   Observação: Se você receber um erro x509: certificate signed by unknown authority, sua estação de trabalho não confia no certificado de CA usado no GDC. Siga o procedimento da sua organização para verificar o repositório de certificação confiável da sua estação de trabalho.
   Aviso: usar --login-config-cert com um certificado não verificado deixa você vulnerável a ataques man-in-the-middle. Confie apenas no repositório de confiança da sua estação de trabalho em vez de confiar em um certificado de CA de fontes desconhecidas.

2. Exporte o arquivo kubeconfig de identidade do usuário como uma variável:

   export KUBECONFIG=/tmp/CLUSTER_NAME-ZONE-kubeconfig-with-user-identity.yaml
   

3. Gere um arquivo kubeconfig para um cluster zonal com a identidade do usuário:

   gdcloud clusters get-credentials CLUSTER_NAME --zone ZONE
   

   Substitua ZONE pelo nome da zona.

   Importante: o apiserver global não está vinculado a nenhuma zona. Portanto, execute esse comando sem a flag zone para gerar o kubeconfig do apiserver global: gdcloud clusters get-credentials global-api.
   Observação: a lista de nomes de clusters disponíveis está no URL de configuração de login:
   https://GDC_URL/.well-known/login-config.

   Um arquivo kubeconfig é gerado com a identidade do usuário. O arquivo YAML a seguir mostra um exemplo:

   apiVersion: v1
   clusters:
   - cluster:
     certificate-authority-data: <REDACTED>
     server: https://10.200.0.32:443
   name: cluster-name
   contexts:
   - context:
     cluster: cluster-name
     user: cluster-name-anthos-default-user
   name: cluster-name-cluster-name-anthos-default-user
   current-context: cluster-name-cluster-name-anthos-default-user
   kind: Config
   preferences: {}
   users:
   - name: cluster-name-anthos-default-user
   user:
     exec:
       apiVersion: client.authentication.k8s.io/v1
       args:
       - --audience=root-admin
       command: gdcloud-k8s-auth-plugin
       env: null
       installHint: Run 'gdcloud components install gdcloud-k8s-auth-plugin' to use plugin
       interactiveMode: Never
       provideClusterInfo: false
   

4. Para verificar se você pode acessar o cluster, faça login com o arquivo kubeconfig gerado com uma identidade de usuário:

   kubectl --kubeconfig /tmp/admin-kubeconfig-with-user-identity.yaml version
   

Sair

Para sair do console do GDC, faça o seguinte:

Console

Clique em Sair na barra de menu.

CLI

Saia da CLI:

gdcloud auth revoke

Observação: qualquer página que dependa de recursos do Kubernetes não funciona. O console de depuração do Chrome mostra erros "proibidos" nas respostas. Esse erro ocorre porque o usuário não tem permissões concedidas e não está vinculado a nenhum papel. Consulte Conceder acesso a recursos para instruções sobre como conceder permissões.

Gerar arquivo kubeconfig manualmente

Se você estiver gerenciando recursos com a CLI kubectl chamando APIs KRM diretamente, será necessário gerar o arquivo kubeconfig para o cluster ou servidor de API que hospeda o recurso, dependendo do tipo de recurso que você está gerenciando.

Você também precisa conhecer a configuração do universo do GDC para determinar as zonas em que pretende implantar seus recursos zonais ou o servidor de API global para recursos globais. Para mais informações, consulte Servidores de API globais e zonais.

Determine se o recurso que você está manipulando é global ou zonal. Acesse a documentação dedicada do recurso para receber ajuda se não tiver certeza.

Conclua a configuração aplicável com base no tipo de recurso.

Recursos do servidor da API Management zonal

Siga estas etapas para gerar o arquivo kubeconfig do servidor da API Management zonal:

1. Confira todas as zonas disponíveis:

   gdcloud zones list
   

   Anote o nome da zona que hospeda seu recurso personalizado.

2. Defina a variável de ambiente ZONE como a zona que hospeda seus recursos zonais:

   export ZONE="ZONE"
   

   Substitua ZONE pelo nome da zona.

3. Defina a variável de ambiente MANAGEMENT_API_SERVER:

   export MANAGEMENT_API_SERVER="ORG_NAME-admin"
   

   Substitua ORG_NAME pelo nome da sua organização, como org-1.

4. Gere o arquivo kubeconfig do servidor da API Management para a zona de destino e valide as credenciais:

   export KUBECONFIG=${HOME}/${MANAGEMENT_API_SERVER:?}-kubeconfig.yaml
   rm ${KUBECONFIG:?}
   gdcloud clusters get-credentials ${MANAGEMENT_API_SERVER:?} --zone ${ZONE:?}
   [[ $(kubectl config current-context) == *${MANAGEMENT_API_SERVER:?}* ]] && echo "Success. Your kubeconfig is at $KUBECONFIG" || echo "Failure"
   

   O comando rm ${KUBECONFIG:?} remove o arquivo kubeconfig atual no diretório inicial. Quando você gera um novo arquivo kubeconfig, ele substitui o arquivo atual. Se você não quiser substituir ou remover o arquivo atual, faça backup dele em outro local seguro.

Recursos do cluster do Kubernetes zonal

Siga estas etapas para gerar o arquivo kubeconfig do cluster do Kubernetes zonal:

1. Confira todas as zonas disponíveis:

   gdcloud zones list
   

   Anote o nome da zona que hospeda seu recurso personalizado.

2. Defina a variável de ambiente ZONE como a zona que hospeda o cluster do Kubernetes:

   export ZONE="ZONE"
   

   Substitua ZONE pelo nome da zona.

3. Defina a variável de ambiente KUBERNETES_CLUSTER:

   export KUBERNETES_CLUSTER="KUBERNETES_CLUSTER_NAME"
   

   Substitua KUBERNETES_CLUSTER_NAME pelo nome do cluster do Kubernetes.

4. Gere o arquivo kubeconfig do cluster do Kubernetes para a variável de zona de destino e valide as credenciais:

   export KUBECONFIG=${HOME}/${KUBERNETES_CLUSTER:?}-kubeconfig.yaml
   rm ${KUBECONFIG:?}
   gdcloud clusters get-credentials ${KUBERNETES_CLUSTER:?} --zone ${ZONE:?}
   [[ $(kubectl config current-context) == *${KUBERNETES_CLUSTER:?}* ]] && echo "Success. Your kubeconfig is at $KUBECONFIG" || echo "Failure"
   

   O comando rm ${KUBECONFIG:?} remove o arquivo kubeconfig atual no diretório inicial. Quando você gera um novo arquivo kubeconfig, ele substitui o arquivo atual. Se você não quiser substituir ou remover o arquivo atual, faça backup dele em outro local seguro.

Recursos do servidor de API global

Siga estas etapas para gerar o arquivo kubeconfig do servidor de API global:

1. Defina a variável de ambiente GLOBAL_API_SERVER:

   export GLOBAL_API_SERVER="global-api"
   

2. Gere o arquivo kubeconfig do servidor de API global e valide as credenciais:

   export KUBECONFIG=${HOME}/${GLOBAL_API_SERVER:?}-kubeconfig.yaml
   rm ${KUBECONFIG:?}
   gdcloud clusters get-credentials ${GLOBAL_API_SERVER:?}
   [[ $(kubectl config current-context) == *${GLOBAL_API_SERVER:?}* ]] && echo "Success. Your kubeconfig is at $KUBECONFIG" || echo "Failure"
   

   O comando rm ${KUBECONFIG:?} remove o arquivo kubeconfig atual no diretório inicial. Quando você gera um novo arquivo kubeconfig, ele substitui o arquivo atual. Se você não quiser substituir ou remover o arquivo atual, faça backup dele em outro local seguro.

Logout por inatividade da sessão

Após quinze minutos ou mais de inatividade em uma sessão, o console do GDC e a CLI gdcloud fazem logout. O Distributed Cloud considera a inatividade da sessão como um período durante uma sessão aberta sem engajamento ativo, como nenhum movimento do cursor ou do teclado. Uma sessão ativa dura até doze horas com atividade do usuário.

Console

Para inatividade da sessão, o console do GDC faz logout. Dois minutos antes de o console do GDC fazer logout por inatividade, você recebe uma caixa de diálogo que avisa sobre o logout:

Depois de fazer logout por inatividade, você verá a seguinte tela:

Para fazer login novamente no console do GDC, selecione o provedor de identidade e adicione suas credenciais de login. Se você usar um serviço, como o painel de monitoramento, e o console do GDC fizer logout por inatividade, faça login novamente para ter acesso.

gdcloud

Para inatividade da sessão, a CLI gdcloud faz logout. Depois que a CLI gdcloud fizer logout e você tentar executar um comando, receberá um erro de autorização:

Error: error when creating kube client: unable to create k8sclient: Unauthorized

Para fazer login novamente no GDC, siga as etapas da CLI em Fazer login.

Se você fizer login novamente no GDC por um servidor da API Management, o arquivo kubeconfig será atualizado automaticamente. Para evitar a atualização do arquivo kubeconfig, use a flag --skip-kubeconfig-update no comando gdcloud auth login.

Observação: comandos que não fazem solicitações de API, como gdcloud init e gdcloud config, não são contabilizados na sua atividade. Ao usar esses comandos, a CLI gdcloud faz logout mesmo assim.

kubectl

A CLI gdcloud expira os arquivos kubeconfig após a inatividade da sessão. Se você tentar executar um comando kubectl após a inatividade, receberá um erro de autorização:

error: You must be logged in to the server (Unauthorized)

Para fazer login novamente e usar o arquivo kubeconfig, siga as etapas da CLI em Fazer login. Para cada tempo limite de sessão, é necessário regenerar os arquivos kubeconfig.

Monitorar atividades de login e de novos usuários

Atividades como o login são exportadas como registros de auditoria. Para mais informações sobre como visualizar registros de auditoria, consulte Registros de auditoria.