Configurar o gateway do Connect

Este guia é destinado a administradores de plataformas que precisam configurar o gateway do Connect para uso pelos usuários e contas de serviço do projeto. Com essa configuração, os usuários podem fazer o seguinte:

  • Usar o Console do Google Cloud para fazer login em clusters registrados fora do Google Cloud com a identidade do Google Cloud.

  • Usar kubectl para acessar clusters pelo gateway do Connect.

Essa configuração só permite a autenticação de usuários e serviços com base nos IDs individuais, não na participação no Grupos do Google. Para configurar o suporte de grupos adicionais, consulte Configurar o gateway do Connect com o Grupos do Google.

Se você não conhece o gateway do Connect, consulte nossa visão geral para uma explicação dos conceitos básicos e como ele funciona.

Antes de começar

  1. 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.
    • kubectl para executar comandos em clusters do Kubernetes. Se precisar instalar kubectl, siga estas instruções

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

  2. Inicialize a CLI do gcloud para usar no projeto ou execute os comandos a seguir para autorizá-la e definir o projeto como padrão:

    gcloud auth login
gcloud config set project PROJECT_ID

Papéis do IAM necessários para a configuração

Este guia pressupõe que você tenha a permissão roles/owner no seu projeto. Se você não for um proprietário do projeto, peça que ele conceda permissões adicionais no projeto para que você possa realizar as seguintes tarefas:

  • Para ativar as APIs, é necessário ter a permissão serviceusage.services.enable, incluída no papel Administrador de uso do serviço (roles/serviceusage.serviceUsageAdmin). Um proprietário de projeto pode criar um papel personalizado com a permissão serviceusage.services.enable ativada ou conceder a você roles/serviceusage.serviceUsageAdmin, da seguinte maneira:

    gcloud projects add-iam-policy-binding PROJECT_ID \
   --member user:USER_EMAIL_ADDRESS \
   --role='roles/serviceusage.serviceUsageAdmin'

  • Para conceder permissões do IAM a usuários e contas de serviço para que eles possam usar o gateway do Connect, você precisa do papel Administrador do IAM do projeto (roles/resourcemanager.projectIamAdmin), que O proprietário do projeto pode conceder o seguinte comando:

    gcloud projects add-iam-policy-binding PROJECT_ID \
   --member user:USER_EMAIL_ADDRESS \
   --role='roles/resourcemanager.projectIamAdmin'

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.

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

Verificar clusters registrados

Somente clusters registrados na rota do projeto podem ser acessados pelo gateway do Connect. Os clusters do GKE no local e em outras nuvens públicas são registrados automaticamente quando são criados. No entanto, os clusters do GKE no Google Cloud e os clusters anexados precisam ser registrados separadamente. Se você precisar registrar um cluster, siga as instruções nos guias de registro de cluster. Os clusters do GKE precisam estar registrados na frota para usar o gateway.

Para verificar se os clusters foram registrados, execute o seguinte comando:

gcloud container fleet memberships list

Você verá uma lista de todos os clusters registrados, como neste exemplo de resposta:

NAME         EXTERNAL_ID
cluster-1    0192893d-ee0d-11e9-9c03-42010a8001c1
cluster-2    f0e2ea35-ee0c-11e9-be79-42010a8400c2

Conceda papéis de IAM a usuários.

O acesso aos clusters é controlado pelo Identity and Access Management (IAM). Os papéis do IAM necessários para acessar clusters usando kubectl são um pouco diferentes dos papéis para acessar clusters no console do Google Cloud, conforme explicado nas seções a seguir.

Conceder papéis para acesso por meio do kubectl

Os usuários e as contas de serviço precisam dos seguintes papéis do IAM para usar o kubectl a fim de interagir com clusters por meio do gateway do Connect, a menos que o usuário tenha roles/owner no projeto:

  • roles/gkehub.gatewayAdmin: este papel permite que um usuário acesse a API Connect Gateway para usar kubectl para gerenciar o cluster.

    • Se um usuário precisar apenas de acesso somente leitura aos clusters conectados, conceda a roles/gkehub.gatewayReader.

    • Se um usuário precisar de acesso de leitura/gravação aos clusters conectados, conceda roles/gkehub.gatewayEditor.

  • roles/gkehub.viewer: esse papel permite que um usuário recupere kubeconfigs do cluster.

Para ver detalhes sobre as permissões incluídas nesses papéis, consulte Papéis do GKE Hub na documentação do IAM.

Use os seguintes comandos para conceder esses papéis:

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=MEMBER \
    --role=GATEWAY_ROLE
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=MEMBER \
    --role=roles/gkehub.viewer

em que:

  • MEMBER é a conta de usuário ou de serviço no formato user|serviceAccount:emailID. Por exemplo:

    • user:alice@example.com
    • serviceAccount:test_sa@example-project.iam.gserviceaccount.com

  • GATEWAY_ROLE é roles/gkehub.gatewayAdmin, roles/gkehub.gatewayReader ou roles/gkehub.gatewayEditor.

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

Conceder papéis para acesso pelo console do Google Cloud

Os usuários que querem interagir com clusters fora do Google Cloud usando o console do Google Cloud precisam ter os papéis do IAM a seguir para visualizar os clusters:

  • roles/container.viewer. Com esse papel, os usuários podem ver a página "Clusters do GKE" e outros recursos do contêiner no console do Google Cloud. Para detalhes sobre as permissões incluídas nesse papel, consulte Papéis do Kubernetes Engine na documentação do IAM.

  • roles/gkehub.viewer. Com esse papel, os usuários podem ver os clusters fora do Google Cloud no console do Google Cloud. Esse é um dos papéis necessários para o acesso a kubectl. Se você já concedeu esse papel a um usuário, não é necessário fazer isso novamente. Para ver detalhes sobre as permissões incluídas nesse papel, consulte Papéis do GKE Hub na documentação do IAM.

    Nos comandos a seguir, substitua PROJECT_ID pelo ID do projeto host da frota. Além disso, substitua MEMBER pelo endereço de e-mail ou pela conta de serviço do usuário usando o formato user|serviceAccount:emailID, por exemplo:

    • user:alice@example.com
    • serviceAccount:test_sa@example-project.iam.gserviceaccount.com
    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=MEMBER \
    --role=roles/container.viewer
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=MEMBER \
    --role=roles/gkehub.viewer

Para mais informações sobre a concessão de papéis do IAM, consulte Gerenciar o acesso a projetos, pastas e organizações na documentação do IAM.

Configurar a autorização do RBAC

O servidor da API Kubernetes de cada cluster precisa autorizar as solicitações provenientes do Console do Google Cloud ou de comandos kubectl provenientes do gateway do Connect dos usuários e das contas de serviço especificadas. Para garantir isso, é necessário atualizar as políticas de controle de acesso baseado em papéis (RBAC) em cada cluster que você quer tornar acessível usando o gateway. É necessário adicionar ou atualizar as seguintes políticas:

  • Uma política de representação que autoriza o agente do Connect a enviar solicitações ao servidor da API Kubernetes em nome de um usuário.
  • Uma política de permissões que especifica quais permissões o usuário tem no cluster. Pode ser um papel no nível do cluster, como clusterrole/cluster-admin ou clusterrole/cloud-console-reader, ou um papel no nível do namespace, como role/default/pod-reader.

(Opcional) Criar um papel cloud-console-reader

Os usuários autenticados que querem acessar os recursos de um cluster no Console do Google Cloud precisam ter as permissões relevantes do Kubernetes para fazer isso. Se você não quiser conceder a esses usuários permissões mais abrangentes, como as de um administrador de cluster, crie um papel personalizado de RBAC que inclua as permissões mínimas para visualizar os nós, volumes permanentes, pods e classes de armazenamento do cluster. Para definir esse conjunto de permissões, crie um recurso de RBAC ClusterRole, cloud-console-reader, no cluster.

cloud-console-reader concede aos usuários as permissões get, list e watch nos nós, volumes permanentes, pods e classes de armazenamento do cluster, o que permite que eles vejam detalhes sobre esses recursos.

kubectl

Para criar o ClusterRole do cloud-console-reader e aplicá-lo ao cluster, execute o seguinte comando:

cat <<EOF > cloud-console-reader.yaml
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: cloud-console-reader
rules:
- apiGroups: [""]
  resources: ["nodes", "persistentvolumes", "pods"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["storage.k8s.io"]
  resources: ["storageclasses"]
  verbs: ["get", "list", "watch"]
EOF
kubectl apply -f cloud-console-reader.yaml

É possível conceder esse papel aos usuários ao configurar suas políticas de permissão, conforme descrito na próxima seção.

Criar e aplicar políticas de RBAC necessárias

Confira a seguir como criar e aplicar as políticas necessárias do RBAC. A maneira mais simples de fazer isso é usando a CLI do gcloud para gerar e aplicar as políticas adequadas. Se preferir, é possível criar um arquivo de política de RBAC e aplicá-lo com kubectl.

gcloud

Para gerar e aplicar as políticas ao cluster escolhido com a CLI gcloud, execute o comando a seguir:

gcloud container fleet memberships generate-gateway-rbac  \
    --membership=MEMBERSHIP_NAME \
    --role=ROLE \
    --users=USERS \
    --project=PROJECT_ID \
    --kubeconfig=KUBECONFIG_PATH \
    --context=KUBECONFIG_CONTEXT \
    --apply

Substitua:

  • MEMBERSHIP_NAME: o nome usado para representar o cluster na frota dele de forma exclusiva. Saiba como verificar o nome da assinatura do cluster em Ver o status de assinatura da frota.
  • ROLE: o papel do Kubernetes que você quer conceder aos usuários no cluster, por exemplo, clusterrole/cluster-admin, clusterrole/cloud-console-reader ou role/mynamespace/namespace-reader. Esse papel já precisa existir antes da execução do comando.
  • USERS: os endereços de e-mail dos usuários (contas de usuário ou contas de serviço) aos quais você quer conceder as permissões como uma lista separada por vírgulas. Por exemplo, --users=foo@example.com,test-acct@test-project.iam.gserviceaccount.com.
  • PROJECT_ID: o ID do projeto em que o cluster está registrado.
  • KUBECONFIG_PATH: o caminho de arquivo local em que o kubeconfig que contém uma entrada do cluster é armazenado. Na maioria dos casos é $HOME/.kube/config.

  • KUBECONFIG_CONTEXT: o contexto do cluster como ele aparece no arquivo kubeconfig. É possível conseguir o contexto atual pela linha de comando executando kubectl config current-context. Independentemente de usar o contexto atual ou não, verifique se ele funciona para acessar o cluster executando o seguinte comando:

    kubectl get namespaces \
  --kubeconfig=KUBECONFIG_PATH \
  --context=KUBECONFIG_CONTEXT

Depois de executar gcloud container fleet memberships generate-gateway-rbac, você verá algo como o seguinte no fim da saída, de maneira truncada para facilitar a leitura

Validating input arguments.
Specified Cluster Role is: clusterrole/cluster-admin
Generated RBAC policy is:
--------------------------------------------
...
---
Applying the generate RBAC policy to cluster with kubeconfig: artifacts/kubeconfig, context: example-cluster-admin@example-cluster
Writing RBAC policy for user: 222larabrown@gmail.com to cluster.
Successfully applied the RBAC policy to cluster.

Esse é o contexto para acessar o cluster pelo gateway do Connect.

Para mais detalhes sobre o comando generate-gateway-rbac, consulte o guia de referência da CLI gcloud.

Se você vir um erro como ERROR: (gcloud.container.hub.memberships) Invalid choice: 'generate-gateway-rbac' ao executar esse comando, atualize a Google Cloud CLI seguindo o guia de atualização.

kubectl

O exemplo a seguir mostra como criar políticas adequadas para um usuário (foo@example.com) e uma conta de serviço (test@example-project.iam.gserviceaccount.com), concedendo a ele as duas permissões cluster-admin no cluster e salvando o arquivo de política como /tmp/gateway-rbac.yaml. Em seguida, as políticas são aplicadas ao cluster associado ao contexto atual:

cat <<EOF > /tmp/gateway-rbac.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: gateway-impersonate
rules:
- apiGroups:
  - ""
  resourceNames:
  - foo@example.com
  - test@example-project.iam.gserviceaccount.com
  resources:
  - users
  verbs:
  - impersonate
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: gateway-impersonate
roleRef:
  kind: ClusterRole
  name: gateway-impersonate
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: ServiceAccount
  name: connect-agent-sa
  namespace: gke-connect
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: gateway-cluster-admin
subjects:
- kind: User
  name: foo@example.com
- kind: User
  name: test@example-project.iam.gserviceaccount.com
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io
EOF
# Apply policies to the cluster.
kubectl apply --kubeconfig=KUBECONFIG_PATH  -f /tmp/gateway-rbac.yaml

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

Suporte do VPC Service Controls

O VPC Service Controls oferece uma camada adicional de defesa de segurança para serviços do Google Cloud, independente do gerenciamento de identidade e acesso (IAM, na sigla em inglês). Enquanto o IAM permite um controle de acesso baseado em identidade granular, o VPC Service Controls permite uma segurança de perímetro baseada em contexto mais ampla, incluindo o controle da saída de dados em todo o perímetro. Por exemplo, é possível especificar que apenas determinados projetos possam acessar seus dados do BigQuery. Para saber mais sobre como o VPC Service Controls funciona para proteger seus dados, consulte a Visão geral do VPC Service Controls.

É possível usar o VPC Service Controls com o gateway do Connect para aumentar a segurança dos dados, garantindo que as APIs necessárias para usar o gateway possam ser acessadas de dentro do perímetro de serviço especificado.

A seguir