Como 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. Antes de ler este guia, você precisa conhecer os conceitos da nossa visão geral.

Essa configuração permite que os usuários utilizem o gateway do Connect diretamente e se conectem a clusters registrados fora do Google Cloud com a identidade do Google Cloud no Console do Cloud, conforme descrito em Como fazer login em um cluster no Console do Cloud.

Essa configuração só permite a autorizaçã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.

Antes de começar

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

    • A versão mais recente do SDK do Cloud, que inclui a gcloud, a ferramenta de linha de comando para interagir com o Google Cloud.
    • kubectl

    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 ferramenta de linha de comando 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.

Ative as 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 Cloud, você não precisará ativar o 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

Verificar clusters registrados

Somente clusters registrados na rota do projeto podem ser acessados pelo gateway do Connect. Os clusters do Anthos 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 em Como registrar um cluster. Os clusters do GKE precisam ser registrados no agente do Connect para usar o gateway.

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

gcloud container hub 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.

Usuários e contas de serviço precisam dos seguintes papéis adicionais do Google Cloud para interagir com clusters conectados por meio do gateway, a menos que o usuário ou a conta tenha roles/owner no projeto:

  • roles/gkehub.gatewayAdmin Este papel permite que um usuário acesse a API do gateway do Connect.
    • Se um usuário precisar apenas de acesso somente leitura a clusters conectados, roles/gkehub.gatewayReader poderá ser usado.
  • roles/gkehub.viewer. Este papel permite que um usuário recupere as credenciais do cluster.

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


# [PROJECT_ID] is the project's unique identifier.
# [ACCOUNT_ADDRESS] is an email address, which can belong to either a user account or a service account

PROJECT_ID=example_project

# MEMBER should be of the form `user|serviceAccount:$ACCOUNT_ADDRESS`, for example:
# MEMBER=user:foo@example.com
# MEMBER=serviceAccount:test@example-project.iam.gserviceaccount.com

MEMBER=user:foo@example.com

# GATEWAY_ROLE should be `roles/gkehub.gatewayAdmin` or `roles/gkehub.gatewayReader`.
GATEWAY_ROLE=roles/gkehub.gatewayAdmin

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

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 por meio do Console do Cloud

Para usuários que querem interagir somente com clusters conectados usando o Console do Cloud. são necessários os seguintes papéis:

  • roles/gkehub.viewer. Este papel permite que o usuário visualize os clusters na página do console do GKE.
  • roles/container.viewer. Esse papel permite que o usuário visualize os recursos do contêiner no Console do Cloud.

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

Por fim, o servidor da API Kubernetes do cluster precisa autorizar os comandos kubectl que passam pelo gateway dos usuários e contas de serviço especificadas. Para garantir isso, você precisa atualizar as políticas de RBAC em cada cluster que quiser tornar acessível por meio do gateway. Há duas políticas que você precisa atualizar ou adicionar:

  • Uma política de falsificação de identidade que autoriza o agente do Connect a enviar solicitações ao servidor da API Kubernetes em nome de um usuário. O exemplo a seguir mostra como criar e aplicar essa política para um usuário (foo@example.com) e uma conta de serviço (test@example-project.iam.gserviceaccount.com), salvando o arquivo de política como /tmp/impersonate.yaml e aplicando ao cluster associado ao contexto atual:
cat <<EOF > /tmp/impersonate.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
EOF
# Apply impersonation policy to the cluster.
kubectl apply -f /tmp/impersonate.yaml

Isso não garante que a solicitação em si será autorizada pelo servidor da API. Para fazer isso, você também precisa dar explicitamente a cada conta permissões RBAC adequadas para executar operações do Kubernetes, como descrito abaixo.

  • Uma política de permissões que especifica quais permissões o usuário tem no cluster. O exemplo a seguir mostra como conceder a um usuário e uma conta de serviço permissões cluster-admin no cluster, salvando o arquivo de política como /tmp/admin-permission.yaml e aplicando-o ao cluster associado ao contexto atual.
cat <<EOF > /tmp/admin-permission.yaml
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 permission policy to the cluster.
kubectl apply -f /tmp/admin-permission.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