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 serviço do projeto, usando o 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 Google Cloud console.

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

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 dos Grupos do Google para cada usuário que faz login no cluster. Em seguida, você pode usar essas informações nas políticas de controle de acesso.

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 alice@example.com como membro.

  2. É um grupo aninhado de gke-security-groups@example.com.

Diagrama mostrando o fluxo dos Grupos do Google do gateway

  1. O usuário alice@example.com faz login usando a identidade do Google e, se planeja usar o cluster na linha de comando, recebe o gateway do cluster kubeconfig conforme descrito em Como usar o gateway do Connect.
  2. O usuário envia uma solicitação executando um kubectl comando ou abrindo as páginas Cargas de trabalho ou Navegador de objetos do Google Kubernetes Engine no Google Cloud console.
  3. A solicitação é recebida pelo serviço Connect, que executa uma verificação de autorização com 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 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 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

  1. Faça login na sua Google Cloud conta do. 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.

  2. Instale a Google Cloud CLI.

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

  4. Para inicializar a CLI gcloud, execute o seguinte comando: 

    gcloud init

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

  6. Ative as APIs Connect Gateway, GKE Connect, GKE Hub, Anthos Identity Service e Cloud Resource Manager:

    Funções necessárias para ativar APIs

    Para ativar as APIs, é necessário ter o papel do IAM de administrador de Service Usage role (roles/serviceusage.serviceUsageAdmin), que contém a serviceusage.services.enable permissão. Saiba como conceder papéis. 

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

  7. Instale a Google Cloud CLI.

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

  9. Para inicializar a CLI gcloud, execute o seguinte comando: 

    gcloud init

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

  11. Ative as APIs Connect Gateway, GKE Connect, GKE Hub, Anthos Identity Service e Cloud Resource Manager:

    Funções necessárias para ativar APIs

    Para ativar as APIs, é necessário ter o papel do IAM de administrador de Service Usage role (roles/serviceusage.serviceUsageAdmin), que contém a serviceusage.services.enable permissão. Saiba como conceder papéis. 

    gcloud services enable connectgateway.googleapis.com gkeconnect.googleapis.com gkehub.googleapis.com anthosidentityservice.googleapis.com cloudresourcemanager.googleapis.com
    12.
  12. 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 ter 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 personalizados papéis ou outros predefinidos papéis.

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 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.

Configurar o suporte para grupos

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

As seções a seguir mostram como atualizar o recurso personalizado ClientConfig para ativar o suporte a grupos. Essas seções se aplicam apenas a 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.

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

  • Distributed Cloud conectado: apenas clusters individuais. A configuração no nível da frota não é compatível.
  • Google Distributed Cloud (somente software) no VMware e 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á tiver configurado a autenticação no nível da frota, como para um provedor de identidade diferente, a autenticação de grupo já estará ativada. No entanto, se a política de rede exigir que o tráfego de saída passe por um proxy, será necessário atualizar 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 Google Cloud console do, acesse a página Serviço de Identidade do GKE.

    Acessar o Serviço de Identidade do GKE

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

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

  4. Clique em Atualizar configuração. O painel Editar configuração de clusters do serviço de identidade será 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 provedor de identidade do Google 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 do ClientConfig, adicione o seguinte campo:

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

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

  3. Opcional: se você precisar acessar o provedor de identidade do Google usando 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 à identidade do Google. Por exemplo: http://user:password@10.10.10.10:8888

  4. Aplique a configuração a um cluster na 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 em 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á assim:

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

  2. Abra o ClientConfig default 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.

    Verifique se o campo internalServer tem o valor https://kubernetes.default.svc.

  4. Opcional: se você precisar acessar o provedor de identidade do Google usando 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 à identidade do Google. Por exemplo: http://user:password@10.10.10.10:8888

Conceder papéis do IAM aos Grupos do Google

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

  • roles/gkehub.gatewayAdmin. Esse 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: cluster-admin-team@example.com
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.

A seguir