Configurar o gateway do Connect com o Grupos do Google

Este guia é destinado a administradores de plataformas que precisam configurar o gateway do Connect para uso pelas contas de usuário do projeto, usando os Grupos do Google para autorização. Antes de ler esta página, confira se você conhece os conceitos da nossa visão geral. Para autorizar contas individuais, consulte a configuração padrão.

Com essa configuração, os usuários podem fazer login em clusters de frotas configurados usando a Google Cloud CLI, o gateway do Connect e o console do Google Cloud .

Esse recurso usa os Grupos do Google associados ao Google Workspace ou a qualquer edição do Cloud Identity.

Tipos de cluster compatíveis

É possível configurar o controle de acesso com os Grupos do Google pelo gateway do Connect para os seguintes tipos de cluster:

• GKE no Google Cloud: todas as versões disponíveis. Para configurar o gateway de conexão, configure os Grupos do Google para RBAC e, em seguida, conceda papéis do IAM aos Grupos do Google.
• Google Distributed Cloud (somente software) no VMware e bare metal: todas as versões disponíveis.
• Google Distributed Cloud conectado: todas as versões disponíveis.
• Clusters anexados ao GKE: versão 1.28.0-gke.2 e mais recentes.

• GKE na AWS e GKE no Azure: todas as versões disponíveis.

  Atenção: o GKE na AWS e o GKE no Azure foram descontinuados. Para mais informações, consulte o comunicado de descontinuação do GKE na AWS e o comunicado de descontinuação do GKE no Azure.

Para usar esse recurso com ambientes que não estão na lista anterior, entre em contato com o Cloud Customer Care ou a equipe de gateway do Connect.

Como funciona

Conforme descrito na visão geral, geralmente é útil poder conceder aos usuários acesso a clusters com base na participação deles nos Grupos do Google, ou seja, grupos criados no Google Workspace. Autorizar com base na associação ao grupo significa que você não precisa configurar uma autorização separada para cada conta, o que simplifica o gerenciamento das políticas e facilita a auditoria. Por exemplo, é fácil compartilhar o acesso ao cluster para uma equipe, eliminando a necessidade de adicionar/remover manualmente usuários individuais dos clusters quando eles ingressam ou saem da equipe. É possível configurar o gateway do Connect para receber informações de associação aos Grupos do Google para cada usuário que faz login no cluster. Em seguida, use essas informações nas políticas de controle de acesso.

Observação: contas de serviço (que terminam em gserviceaccount.com) não são compatíveis com a funcionalidade dos Grupos do Google.

Confira a seguir o fluxo típico de um usuário fazendo a autenticação e a execução de comandos em um cluster com esse serviço ativado. Para que esse fluxo seja bem-sucedido, é necessário haver uma política de RBAC no cluster para um grupo que:

1. Contém o usuário [e-mail] como membro.

2. É um grupo aninhado de [e-mail].

1. O usuário [e-mail] faz login usando a Google Identity e, se planeja usar o cluster na linha de comando, recebe o gateway kubeconfig do cluster, conforme descrito em Como usar o gateway do Connect.
2. O usuário envia uma solicitação executando um comando kubectl ou abrindo as páginas Cargas de trabalho ou Navegador de objetos do Google Kubernetes Engine no consoleGoogle Cloud .
3. A solicitação é recebida pelo serviço Connect, que executa uma verificação de autorização com o IAM.
4. O serviço do Connect encaminha a solicitação ao agente do Connect em execução no cluster. A solicitação é acompanhada das informações de credenciais do usuário para uso na autenticação e autorização no cluster.
5. O agente do Connect encaminha a solicitação para o servidor de API do Kubernetes.
6. O servidor de API Kubernetes encaminha a solicitação para o pod anthos-identity-service no cluster, que valida a solicitação.
7. O pod anthos-identity-service retorna as informações do usuário e do grupo para o servidor de API Kubernetes. O servidor de API Kubernetes pode usar essas informações para autorizar a solicitação com base nas políticas de RBAC configuradas do cluster.

Antes de começar

Faça login na sua conta do Google Cloud . Se você começou a usar o Google Cloudagora, crie uma conta para avaliar o desempenho dos nossos produtos em situações reais. Clientes novos também recebem US $300 em créditos para executar, testar e implantar cargas de trabalho sem custos financeiros.

Instale a CLI do Google Cloud.

Observação:se você já instalou a CLI gcloud, execute o comando gcloud components update para verificar se tem a versão mais recente.

Ao usar um provedor de identidade (IdP) externo, primeiro faça login na CLI gcloud com sua identidade federada.

Para inicializar a CLI gcloud, execute o seguinte comando:

gcloud init

Verifique se você tem as permissões necessárias para concluir este guia.

Ative as APIs Connect Gateway, GKE Connect, GKE Hub, Anthos Identity Service e Cloud Resource Manager, se ainda não estiverem ativadas:

Funções necessárias para ativar APIs

Para ativar APIs, você precisa da permissão serviceusage.services.enable. Se você criou o projeto, provavelmente já tem essa permissão pelo papel de proprietário (roles/owner). Caso contrário, é possível conseguir essa permissão pelo papel de administrador do Service Usage (roles/serviceusage.serviceUsageAdmin). Saiba como conceder papéis.

gcloud services enable connectgateway.googleapis.com gkeconnect.googleapis.com gkehub.googleapis.com anthosidentityservice.googleapis.com cloudresourcemanager.googleapis.com

Instale a CLI do Google Cloud.

Observação:se você já instalou a CLI gcloud, execute o comando gcloud components update para verificar se tem a versão mais recente.

Ao usar um provedor de identidade (IdP) externo, primeiro faça login na CLI gcloud com sua identidade federada.

Para inicializar a CLI gcloud, execute o seguinte comando:

gcloud init

Verifique se você tem as permissões necessárias para concluir este guia.

Ative as APIs Connect Gateway, GKE Connect, GKE Hub, Anthos Identity Service e Cloud Resource Manager, se ainda não estiverem ativadas:

Funções necessárias para ativar APIs

Para ativar APIs, você precisa da permissão serviceusage.services.enable. Se você criou o projeto, provavelmente já tem essa permissão pelo papel de proprietário (roles/owner). Caso contrário, é possível conseguir essa permissão pelo papel de administrador do Service Usage (roles/serviceusage.serviceUsageAdmin). Saiba como conceder papéis.

gcloud services enable connectgateway.googleapis.com gkeconnect.googleapis.com gkehub.googleapis.com anthosidentityservice.googleapis.com cloudresourcemanager.googleapis.com

1. Para clusters fora do Google Cloud, os componentes de autenticação no seu cluster precisam chamar a API Cloud Identity. Verifique se você tem políticas de rede que exigem que o tráfego de saída do cluster passe por um proxy.

Funções exigidas

Para receber as permissões necessárias para configurar o gateway do Connect e os clusters, peça ao administrador para conceder a você o papel do IAM de Editor (roles/editor) no projeto. Para mais informações sobre a concessão de papéis, consulte Gerenciar o acesso a projetos, pastas e organizações.

Também é possível conseguir as permissões necessárias usando papéis personalizados ou outros papéis predefinidos.

Configurar usuários e grupos

Verifique se os grupos que você quer usar com este recurso estão configurados da seguinte maneira:

1. Verifique se há um grupo no Google Workspace da sua organização com o formato gke-security-groups@YOUR-DOMAIN. Se você não tiver um grupo desse tipo, siga as instruções em Criar um grupo na sua organização usando o Google Admin Console.
2. Siga as instruções em Adicionar um grupo a outro grupo para adicionar os grupos que você quer usar para controle de acesso como grupos aninhados de gke-security-groups. Não adicione usuários individuais como membros de gke-security-groups.

As contas de usuário que você quer usar com esse recurso devem usar o mesmo nome de domínio do grupo.

Observação: o número de grupos retornados para um usuário no grupo gke-security-groups é limitado pelo tamanho máximo de 8 KB do cabeçalho HTTP. Embora não haja um limite rígido para o número de grupos, nomes de grupos longos podem fazer com que a solicitação exceda esse limite e resulte em erros que podem exigir que você reestruture a hierarquia do grupo.

Configurar o suporte para grupos

O gateway do Connect usa componentes de autenticação no seu cluster para recuperar informações de associação a grupos. Para ativar os componentes necessários, consulte um dos seguintes documentos, dependendo do tipo de cluster:

• GKE no Google Cloud: configure os Grupos do Google para RBAC e pule para a seção Conceder papéis do IAM a grupos.
• Clusters anexados do GKE:
  • Acessar o cluster anexado do EKS
  • Acessar o cluster anexado do AKS
  • Acessar outros tipos de cluster

• Google Distributed Cloud: ative o suporte para grupos atualizando o recurso personalizado ClientConfig no cluster. O Distributed Cloud cria automaticamente um ClientConfig chamado default no namespace kube-public em todos os clusters. Para verificar se esse recurso personalizado existe, execute o seguinte comando:

  kubectl --kubeconfig CLUSTER_KUBECONFIG get ClientConfig default -n kube-public
  

  Substitua CLUSTER_KUBECONFIG pelo caminho para o kubeconfig do cluster.

As seções a seguir mostram como atualizar o recurso personalizado ClientConfig para ativar o suporte a grupos. Estas seções se aplicam apenas aos clusters do Google Distributed Cloud. Para outros tipos de clusters, como GKE em Google Cloud, GKE na AWS e GKE no Azure, pule para a seção Conceder papéis do IAM a grupos.

No Distributed Cloud, é possível configurar o suporte a grupos para clusters individuais ou para uma frota. O tipo de cluster usado determina como você configura o suporte a grupos, da seguinte maneira:

• Distributed Cloud conectado: somente clusters individuais. A configuração no nível da frota não é compatível.
• Google Distributed Cloud (somente software) no VMware e em bare metal: clusters ou frotas individuais.

Configurar o suporte a grupos usando a API Fleet do GKE

Para o Google Distributed Cloud (somente software) no VMware e bare metal, é possível configurar o suporte a grupos no nível da frota. Se você já configurou a autenticação no nível da frota, como para um provedor de identidade diferente, a autenticação de grupo já está ativada. No entanto, se a política de rede exigir que o tráfego de saída passe por um proxy, atualize a configuração atual com informações sobre esse proxy.

Para configurar o suporte a grupos no nível da frota, selecione uma das seguintes opções:

Console

1. No console do Google Cloud , acesse a página Serviço de Identidade do GKE.

   Acessar o GKE Identity Service

2. Clique em Ativar o serviço de identidade.

3. Selecione os clusters do Google Distributed Cloud (somente software) no VMware e em bare metal que você quer configurar.

4. Clique em Atualizar configuração. O painel Editar configuração de clusters do serviço de identidade é aberto.

5. Na seção Configurar provedores de identidade, você pode escolher reter, adicionar, atualizar ou remover um provedor de identidade.

6. Clique em Continuar para ir para a próxima etapa de configuração. Se você tiver selecionado pelo menos um cluster qualificado para essa configuração, a seção Autenticação do Google será exibida.

7. Selecione Ativar para habilitar a autenticação do Google para os clusters selecionados. Se você precisar acessar o Google Identity usando um proxy, digite os detalhes do Proxy.

8. Clique em Atualizar configuração. Isso aplica a configuração de identidade nos clusters selecionados.

gcloud

1. Ative o recurso de serviço de identidade no nível da frota e configure os clusters, conforme descrito em Configurar o gerenciamento de autenticação no nível da frota.

2. No arquivo auth-config.yaml que contém a especificação ClientConfig, adicione o seguinte campo:

   spec:
     authentication:
     - name: google-authentication-method
       google:
         disable: false
   

   O valor de false no campo google.disable ativa o suporte a grupos. Para desativar o suporte a grupos, mude esse valor para true.

3. Opcional: se você precisar acessar o Google Identity por meio de um proxy, adicione o campo proxy à configuração anterior:

   spec:
     authentication:
     - name: google-authentication-method
       google:
         disable: false
       proxy: PROXY_URL
   

   Substitua PROXY_URL pelo endereço do servidor proxy para se conectar ao Google Identity. Por exemplo: http://user:password@10.10.10.10:8888

4. Aplique a configuração a um cluster na sua frota:

   gcloud container fleet identity-service apply \
   --membership=CLUSTER_NAME \
   --config=/path/to/auth-config.yaml

   Substitua CLUSTER_NAME pelo nome de assinatura exclusivo do cluster na frota.

Depois de configurar o suporte a grupos no nível da frota, o controlador da frota gerencia a configuração. A configuração no nível da frota substitui todas as mudanças locais feitas na configuração de um cluster específico.

Configurar o suporte a grupos para clusters individuais

Para todos os clusters do Distributed Cloud, incluindo o Distributed Cloud conectado, ative o suporte a grupos atualizando o ClientConfig default em cada cluster:

1. Receba os detalhes da assinatura do cluster:

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get memberships membership -o yaml
   

   Substitua USER_CLUSTER_KUBECONFIG pelo caminho do arquivo kubeconfig do cluster. Se houver vários contextos no kubeconfig o contexto atual será usado. Talvez seja necessário redefinir o contexto atual para o cluster correto antes de executar o comando.

   Na resposta, consulte o campo spec.owner.id para recuperar os detalhes da associação do cluster. O identificador de assinatura tem o formato //gkehub.googleapis.com/projects/PROJECT_NUMBER/locations/global/memberships/MEMBERSHIP.

   O resultado será o seguinte:

   id: //gkehub.googleapis.com/projects/123456789/locations/global/memberships/xy-ab12cd34ef
   

2. Abra o default ClientConfig no cluster para edição:

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-public edit clientconfig default
   

3. Para ativar o suporte a grupos, adicione o campo google ao campo spec.authentication:

   spec:
     internalServer: https://kubernetes.default.svc
     authentication:
     - google:
         audiences:
         - "CLUSTER_IDENTIFIER"
       name: google-authentication-method
   

   Substitua CLUSTER_IDENTIFIER pelos detalhes da assinatura do cluster.

   Confira se o campo internalServer tem um valor de https://kubernetes.default.svc.

4. Opcional: se você precisar acessar o Google Identity por meio de um proxy, adicione o campo proxy à configuração anterior:

   spec:
     internalServer: https://kubernetes.default.svc
     authentication:
     - google:
         audiences:
         - "CLUSTER_IDENTIFIER"
       name: google-authentication-method
       proxy: PROXY_URL
   

   Substitua PROXY_URL pelo endereço do servidor proxy para se conectar ao Google Identity. Por exemplo: http://user:password@10.10.10.10:8888

Conceder papéis do IAM aos Grupos do Google

Observação: Ao gerenciar o acesso de usuários em provedores de identidade externos, substitua as instâncias de identificadores principais da Conta do Google, como user:[e-mail], group:[e-mail] e domain:example.com, pelos identificadores principais apropriados da federação de identidade de colaboradores.

Os grupos precisam dos seguintes papéis adicionais do Google Cloud para interagir com clusters conectados pelo gateway:

• roles/gkehub.gatewayAdmin. Esse papel permite que os membros do grupo acessem a API Connect Gateway.
  • Se os membros do grupo só precisarem de acesso somente leitura aos clusters conectados, roles/gkehub.gatewayReader poderá ser usado.
  • Se membros do grupo precisarem de acesso de leitura/gravação aos clusters conectados, roles/gkehub.gatewayEditor poderá ser usado.
• roles/gkehub.viewer). Esse papel permite que os membros do grupo vejam as assinaturas do cluster registradas.

Você concede esses papéis usando o comando gcloud projects add-iam-policy-binding da seguinte maneira:

gcloud projects add-iam-policy-binding --member=group:GROUP_NAME@DOMAIN --role=GATEWAY_ROLE PROJECT_ID
gcloud projects add-iam-policy-binding --member=group:GROUP_NAME@DOMAIN --role=roles/gkehub.viewer PROJECT_ID

onde

• GROUP_NAME é o Grupo do Google a que você quer conceder o papel.
• DOMAIN é seu domínio do Google Workspace.
• GROUP_NAME@DOMAIN é um grupo aninhado em gke-security-groups@DOMAIN
• GATEWAY_ROLE é um dos campos roles/gkehub.gatewayAdmin, roles/gkehub.gatewayReader ou gkehub.gatewayEditor.
• PROJECT_ID é seu projeto

Saiba mais sobre como conceder permissões e papéis do IAM em Como conceder, alterar e revogar acesso a recursos.

Configurar políticas de controle de acesso baseado em papéis (RBAC, na sigla em inglês)

Por fim, o servidor de API Kubernetes de cada cluster precisa autorizar comandos kubectl que passam pelo gateway dos grupos especificados. Para cada cluster, você precisa adicionar uma política de permissões do RBAC que especifica quais permissões o grupo tem no cluster.

No exemplo a seguir, você verá como conceder aos membros do grupo cluster-admin-team permissões cluster-admin no cluster, salvar o arquivo da política como /tmp/admin-permission.yaml e aplicá-lo ao cluster associado no contexto atual. Inclua também o grupo cluster-admin-team no grupo gke-security-groups.

cat <<EOF > /tmp/admin-permission.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: gateway-cluster-admin-group
subjects:
- kind: Group
  name: [e-mail]
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io
EOF
# Apply permission policy to the cluster.
kubectl apply --kubeconfig=KUBECONFIG_PATH -f /tmp/admin-permission.yaml

Saiba mais sobre como especificar permissões de RBAC em Como usar a autorização RBAC.

Observação: Nossos exemplos mostram a aplicação de atualizações de políticas diretamente com kubectl. Para uso real, recomendamos o uso do Controlador de Políticas para criar e gerenciar políticas com o Config Sync para sincronizar essas políticas e outras configurações entre os clusters.

A seguir

• Saiba como usar o gateway do Connect para se conectar a clusters pela linha de comando.
• Confira um exemplo de como usar o gateway de conexão como parte da automação de DevOps no tutorial Como integrar ao Cloud Build.