Configurar o gateway do Connect com Grupos do Google

Este guia é destinado a administradores de plataformas que precisam configurar o gateway do Connect para uso pelas contas de serviço do projeto, usando o Grupos do Google para autorização. Antes de ler este guia, você precisa conhecer 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 CLI do Google Cloud, o gateway do Connect e o console do Google Cloud.

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

Tipos de cluster com suporte

Se você estiver usando clusters do GKE no Google Cloud com o Connect Gateway, não precisará seguir toda essa configuração com o GKE Identity Service para usar Grupos do Google na autorização. Em vez disso, siga as instruções em Configurar Grupos do Google para RBAC, que também permite que os usuários façam login em clusters do GKE no console do Google Cloud usando os Grupos do Google para controle de acesso. Depois de fazer isso, siga as instruções abaixo em Conceder papéis do IAM aos Grupos do Google para permitir que os membros do grupo acessem os clusters pelo gateway do Connect.

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

• Clusters do GKE registrados
• Clusters em implantações do Google Distributed Cloud (no local) no VMware e em bare metal do Anthos (GKE Enterprise), versão 1.13 ou mais recente
• GKE na AWS e GKE no Azure do Kubernetes versão 1.25 e mais recentes.

• Cluster anexados das versões 1.26.0-gke.8, 1.27.0-gke.5, 1.28.0-gke.2 ou mais recentes.

  Se você precisar fazer upgrade dos clusters no local para usar esse recurso, consulte Como fazer upgrade de clusters no VMWare e Como fazer upgrade de clusters em bare metal.

Para usar esse recurso com outros ambientes além dos listados acima, entre em contato com o Cloud Customer Care ou com 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. Com algumas configurações adicionais usando o GKE Identity Service, é possível configurar o gateway do Connect para receber informações de associação do Grupo do Google para cada usuário que faz login no cluster. Em seguida, você pode usar essas informações dos grupos 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 de Grupos do Google.

Veja 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 identidade do Google 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 Console do Google 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 com as informações de credencial 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 da API Kubernetes.
6. O servidor da API Kubernetes encaminha a solicitação para o GKE Identity Service, que valida a solicitação.
7. O serviço de identidade do GKE retorna as informações do usuário e do grupo para o servidor da API Kubernetes. O servidor da 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

• Verifique se você tem as seguintes ferramentas de linha de comando instaladas:

  • A versão mais recente da Google Cloud CLI, a ferramenta de linha de comando para interagir com o Google Cloud.
  • A ferramenta de linha de comando do Kubernetes, kubectl, para interagir com os clusters.

  Se você estiver usando o Cloud Shell como ambiente shell para interagir com o Google Cloud, essas ferramentas estarão instaladas.

• Verifique se você inicializou a CLI gcloud para usar com seu projeto.

• Este guia presume que você tem roles/owner no seu projeto. Se você não for proprietário do projeto, talvez precise de outras permissões para executar algumas das etapas de configuração.

• Para clusters fora do Google Cloud, o GKE Identity Service precisa chamar a API Google Identity a partir do seu cluster. Verifique se a política de rede exige que tráfego de saída passe por um proxy.

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 para criar o grupo no Admin Console do Google Workspace.
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.

Ativar APIs

Para adicionar o gateway ao seu projeto, ative a API do gateway do Connect e as APIs de dependência necessárias. Se os usuários quiserem se autenticarem apenas em clusters usando o console do Google Cloud, você não precisará ativar connectgateway.googleapis.com, mas precisará ativar as APIs restantes.

PROJECT_ID=example_project
gcloud services enable --project=${PROJECT_ID}  \
connectgateway.googleapis.com \
anthos.googleapis.com \
gkeconnect.googleapis.com \
gkehub.googleapis.com \
cloudresourcemanager.googleapis.com

Observação: se você não for proprietário de um projeto, precisará ter a permissão serviceusage.services.enable para ativar as APIs para ele.

Configurar o serviço de identidade do GKE

O recurso de suporte de Grupos do Google do Connect Gateway usa o GKE Identity Service para receber informações de associação a grupos do Google. Saiba mais sobre o serviço de identidade do GKE em Introdução ao serviço de identidade do GKE.

Se você usa clusters do GKE com o gateway, não precisa configurar o GKE Identity Service para usar o suporte de Grupos do Google. Em vez disso, siga as instruções em Configurar o Grupos do Google para RBAC e continue em Conceder papéis do IAM para conceder acesso aos clusters pelo gateway.

Se você está usando clusters anexados do GKE com o gateway, o GKE Identity Service não é necessário para oferecer suporte aos Grupos do Google. Siga as instruções para o tipo de cluster escolhido para configurar o suporte do Grupos do Google:

• Acessar o cluster anexado do EKS
• Acessar o cluster anexado do AKS
• Acessar outros tipos de cluster

Verifique se o serviço de identidade do GKE está instalado

O serviço de identidade do GKE é instalado por padrão nos clusters do GKE a partir da versão 1.7, embora o suporte de Grupos do Google exija a versão 1.13 ou mais recente. Para confirmar se ele está instalado corretamente no cluster, execute o seguinte comando:

kubectl --kubeconfig CLUSTER_KUBECONFIG get all -n anthos-identity-service

Substitua CLUSTER_KUBECONFIG pelo caminho para o kubeconfig do cluster.

Configurar o suporte dos Grupos do Google

Se você está usando o GKE na AWS ou no Azure, seu cluster está configurado automaticamente para oferecer compatibilidade com os Grupos do Google. Você pode pular para Conceder papéis do IAM aos Grupos do Google.

Se você está usando o Google Distributed Cloud no VMware ou em bare metal, a maneira como configurar o serviço de identidade do GKE determina como é preciso configurar o recurso Grupos do Google.

Se você está usando o GKE Identity Service pela primeira vez, é possível escolher entre a configuração do Grupos do Google no nível da frota (recomendado) ou a configuração Por cluster.

Se você não for um usuário novo do GKE Identity Service, lembre-se de que:

• Se você já tiver configurado o GKE Identity Service para outro provedor de identidade no nível da frota, o recurso do Grupos do Google será ativado por padrão. Consulte a seção Frota abaixo para ver mais detalhes e outras configurações necessárias.

• Se você já configurou o GKE Identity Service para outro provedor de identidade por cluster, consulte a seção Por cluster abaixo para ver instruções sobre como atualizar sua configuração para o recurso Grupos do Google.

Frota

Use o console do Google Cloud ou a linha de comando para configurar o acesso aos Grupos do Google no nível da frota.

Se você já tiver configurado o GKE Identity Service no nível da frota com outro provedor de identidade (como Microsoft AD FS ou Okta), o recurso Grupos do Google do gateway do Connect já estará ativado por padrão nos clusters configurados, desde que o provedor de identidade do Google possa ser acessado sem a necessidade de usar um proxy.

Console

Se você ainda não tiver configurado o GKE Identity Service para uma frota, siga as instruções em Configurar clusters para o GKE Identity Service.

Selecionar clusters e atualizar a configuração

1. No console do Google Cloud, acesse a página Gerenciador de recursos.

Acessar o gerenciador de recursos

1. Clique em Detalhes no painel Serviço de identidade. Os detalhes do cluster do projeto são exibidos.
2. Clique em Atualizar serviço de identidade para abrir o painel de configuração.
3. Selecione os clusters que você quer configurar. É possível escolher clusters individuais ou especificar que todos os clusters sejam configurados com a mesma configuração de identidade.
4. Na seção Configurar provedores de identidade, você pode escolher reter, adicionar, atualizar ou remover um provedor de identidade.
5. 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.
6. Selecione Ativar para habilitar a autenticação do Google para os clusters selecionados. Se você precisar acessar o provedor de identidade do Google usando um proxy, digite os detalhes do Proxy.
7. Clique em Atualizar configuração. Isso aplica a configuração de identidade nos clusters selecionados.

gcloud

Se você ainda não tiver configurado o GKE Identity Service para uma frota, siga as instruções em Configurar clusters para o GKE Identity Service. Especifique apenas a seguinte configuração no seu arquivo auth-config.yaml:

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

Configurar o acesso ao Grupos do Google usando um proxy

Se você precisar acessar o provedor de identidade do Google usando um proxy, use um campo proxy no seu arquivo auth-config.yaml. Talvez seja necessário defini-lo se, por exemplo, o cluster estiver em uma rede particular e precisar se conectar a um provedor de identidade público. É necessário adicionar essa configuração mesmo que você já tenha configurado o GKE Identity Service para outro provedor.

Para configurar o proxy, veja como atualizar a seção authentication do arquivo de configuração auth-config.yaml.

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

onde

• disable (opcional) indica se você quer ativar ou desativar o recurso Grupos do Google para clusters. Esse valor é definido como false por padrão. Se você quiser desativar esse recurso, defina-o como true.

• PROXY_URL (opcional) é o endereço do servidor proxy para se conectar à identidade do Google. Por exemplo: http://user:password@10.10.10.10:8888

Aplique a configuração

Para aplicar a configuração a um cluster, execute o seguinte comando:

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

onde

CLUSTER_NAME é o nome de assinatura exclusivo do seu cluster na frota.

Depois de aplicada, essa configuração é gerenciada pelo controlador do GKE Identity Service. Todas as alterações locais feitas na configuração do cliente do GKE Identity Service serão reconciliadas de volta pelo controlador para a configuração especificada nesta configuração.

Por cluster

Para configurar o cluster para usar o GKE Identity Service com o recurso Grupos do Google, é necessário atualizar o ClientConfig do GKE Identity Service do cluster. Esse é um tipo de recurso personalizado (CRD, na sigla em inglês) do Kubernetes usado para a configuração do cluster. Cada cluster do GKE Enterprise tem um recurso ClientConfig chamado default no namespace kube-public que você atualiza com os detalhes da configuração.

Para editar a configuração, use o seguinte comando.

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

em que USER_CLUSTER_KUBECONFIG é o caminho para o 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.

Veja um exemplo de como atualizar o ClientConfig com um novo método de autenticação que tem uma configuração do tipo google para ativar o recurso Grupos do Google: Se o campo internalServer estiver vazio, verifique se ele está definido como https://kubernetes.default.svc, conforme mostrado abaixo.

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

onde

CLUSTER_IDENTIFIER (obrigatório) indica os detalhes de associação do cluster. Use o comando a seguir para recuperar os detalhes de associação do cluster:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get memberships membership -o yaml

onde

USER_CLUSTER_KUBECONFIG é o caminho do arquivo kubeconfig do cluster. Na resposta, consulte o campo spec.owner.id para recuperar os detalhes da associação do cluster.

Veja a seguir um exemplo de resposta que mostra os detalhes de associação de um cluster:

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

que corresponde ao seguinte formato: //gkehub.googleapis.com/projects/PROJECT_NUMBER/locations/global/memberships/MEMBERSHIP

Conceder papéis do IAM aos Grupos do Google

Os grupos precisam dos seguintes papéis extras do Google Cloud para interagir com clusters conectados por meio do gateway:

• roles/gkehub.gatewayAdmin). Este papel permite que os membros do grupo acessem a API do gateway do Connect.
  • 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 da API Kubernetes de cada cluster precisa autorizar os 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 a partir da linha de comando.
• Veja um exemplo de como usar o gateway do Connect como parte da sua automação de DevOps no tutorial Como integrar com o Cloud Build.