Configure o gateway do Connect

Este guia destina-se aos administradores de plataformas que precisam de configurar a gateway Connect para utilização pelos utilizadores e contas de serviço do respetivo projeto. Esta configuração permite que os utilizadores:

  • Usar a Google Cloud consola para iniciar sessão em clusters registados fora Google Cloud com a respetiva Google Cloud identidade.

  • Use kubectl para aceder aos clusters através do gateway Connect.

Esta configuração só permite a autenticação de utilizadores e serviços com base nos respetivos IDs individuais e não na respetiva associação a grupos Google. Para configurar apoio técnico de grupo adicional, consulte o artigo Configure o gateway do Connect com os Grupos Google.

Se não conhece o gateway Connect, consulte a nossa vista geral para uma explicação dos conceitos básicos e como funciona.

Antes de começar

  1. Certifique-se de que tem as seguintes ferramentas de linha de comandos instaladas:

    • A versão mais recente da CLI do Google Cloud, a ferramenta de linha de comandos para interagir com o Google Cloud.
    • kubectl para executar comandos em clusters do Kubernetes. Se precisar de instalar o kubectl, siga estas instruções

    Se estiver a usar o Cloud Shell como ambiente de shell para interagir com o Google Cloud, estas ferramentas são instaladas automaticamente.

  2. Inicialize a CLI gcloud para utilização com o seu projeto ou execute os seguintes comandos para autorizar a CLI gcloud e definir o seu projeto como predefinição:

    gcloud auth login
    gcloud config set project PROJECT_ID
    

Funções IAM necessárias para a configuração

Este guia pressupõe que tem a autorização roles/owner no seu projeto. Se não for proprietário de um projeto, peça a um proprietário de um projeto que lhe conceda autorizações adicionais no projeto para que possa realizar as seguintes tarefas:

  • Para ativar APIs, precisa da autorização serviceusage.services.enable, que está incluída na função Administrador de utilização de serviços (roles/serviceusage.serviceUsageAdmin). Um proprietário do projeto pode criar uma função personalizada com a autorização serviceusage.services.enable ativada ou conceder-lhe roles/serviceusage.serviceUsageAdmin, da seguinte forma:

    gcloud projects add-iam-policy-binding PROJECT_ID \
       --member user:USER_EMAIL_ADDRESS \
       --role='roles/serviceusage.serviceUsageAdmin'
    
  • Para conceder autorizações de IAM a utilizadores e contas de serviço para que possam usar a gateway Connect, precisa da função Administrador de IAM do projeto (roles/resourcemanager.projectIamAdmin), que um proprietário do projeto pode conceder com 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 Connect gateway e as respetivas APIs de dependência necessárias. Se os seus utilizadores só quiserem autenticar-se em clusters usando a Google Cloud consola, não precisa de ativar connectgateway.googleapis.com, mas tem de ativar as outras APIs.

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

Valide os clusters registados

Só é possível aceder aos clusters registados na frota do seu projeto através do gateway do Connect. Os clusters do GKE no local e noutras nuvens públicas são registados automaticamente quando são criados. No entanto, os clusters do GKE em Google Cloud e clusters anexados têm de ser registados separadamente. Se precisar de registar um cluster, siga as instruções nos nossos guias de registo de clusters. Tenha em atenção que os clusters do GKE têm de estar registados na frota para usar o gateway.

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

gcloud container fleet memberships list

Deve ver uma lista de todos os seus clusters registados, como neste exemplo de resultado:

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

Conceda funções IAM aos utilizadores

O acesso aos clusters é controlado pela gestão de identidade e de acesso (IAM). As funções do IAM necessárias para aceder aos clusters através do kubectl diferem ligeiramente das funções para aceder aos clusters na consola Google Cloud , conforme explicado nas secções seguintes.

Conceda funções para acesso através de kubectl

No mínimo, os utilizadores e as contas de serviço precisam das seguintes funções de IAM para usar o kubectl para interagir com clusters através do gateway Connect, a menos que o utilizador tenha roles/owner no projeto:

  • roles/gkehub.gatewayAdmin: esta função permite que um utilizador aceda à API do gateway Connect para usar o kubectl para gerir o cluster. Esta função inclui a autorização gkehub.gateway.stream, que permite aos utilizadores executar os comandos attach, cp e exec kubectl. Para ver requisitos adicionais para executar esses comandos, consulte a secção Suporte de pré-visualização para os comandos.

    • Se um utilizador só precisar de acesso só de leitura a clusters ligados, pode conceder-lhe a função roles/gkehub.gatewayReader.

    • Se um utilizador precisar de acesso de leitura / escrita a clusters ligados, pode conceder roles/gkehub.gatewayEditor.

  • roles/gkehub.viewer: esta função permite que um utilizador obtenha o cluster kubeconfigs.

Para ver detalhes sobre as autorizações incluídas nestas funções, consulte o artigo Funções do GKE Hub na documentação do IAM.

Pode usar os seguintes comandos para conceder estas funções:

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

where:

  • MEMBER é o utilizador ou a conta de serviço, que está 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.

Pode saber mais sobre a concessão de autorizações e funções do IAM em Conceder, alterar e revogar o acesso a recursos.

Atribua funções para acesso através da Google Cloud consola

Os utilizadores que pretendam interagir com clusters fora do Google Cloud através da Google Cloud consola precisam, no mínimo, das seguintes funções de IAM para ver clusters:

  • roles/container.viewer. Esta função permite que os utilizadores vejam a página Clusters do GKE e outros recursos de contentores na Google Cloud consola. Para ver detalhes sobre as autorizações incluídas nesta função, consulte o artigo Funções do Kubernetes Engine na documentação do IAM.

  • roles/gkehub.viewer. Esta função permite que os utilizadores vejam clusters fora do Google Cloud no Google Cloud console. Tenha em atenção que esta é uma das funções necessárias para ter acesso ao kubectl. Se já atribuiu esta função a um utilizador, não precisa de a atribuir novamente. Para ver detalhes sobre as autorizações incluídas nesta função, consulte as funções do GKE Hub na documentação do IAM.

    Nos comandos seguintes, substitua PROJECT_ID pelo ID do projeto anfitrião da frota. Além disso, substitua MEMBER pelo endereço de email ou pela conta de serviço do utilizador 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 como conceder funções da IAM, consulte o artigo Gerir o acesso a projetos, pastas e organizações na documentação da IAM.

Configure a autorização RBAC

O servidor da API Kubernetes de cada cluster tem de poder autorizar pedidos provenientes da Google Cloud consola ou de comandos kubectl provenientes do gateway Connect dos seus utilizadores e contas de serviço especificados. Para garantir isto, tem de atualizar as políticas de controlo de acesso baseado em funções (CABF) em cada cluster que quer tornar acessível através do gateway. Tem de adicionar ou atualizar as seguintes políticas:

  • Uma política de roubo de identidade que autoriza o agente Connect a enviar pedidos para o servidor da API Kubernetes em nome de um utilizador.
  • Uma política de autorizações que especifica as autorizações que o utilizador tem no cluster. Pode ser uma função ao nível do cluster, como clusterrole/cluster-admin ou clusterrole/cloud-console-reader, ou uma função ao nível do espaço de nomes, como role/default/pod-reader.

(Opcional) Crie uma função de cloud-console-reader

Os utilizadores autenticados que queiram aceder aos recursos de um cluster na Google Cloud consola têm de ter as autorizações do Kubernetes relevantes para o fazer. Se não quiser conceder a esses utilizadores autorizações mais extensas, como as de um administrador do cluster, pode criar uma função RBAC personalizada que inclua as autorizações mínimas para ver os nós, os volumes persistentes, os pods e as classes de armazenamento do cluster. Pode definir este conjunto de autorizações criando um recurso ClusterRole RBAC, cloud-console-reader, no cluster.

cloud-console-reader concede aos respetivos utilizadores as autorizações get, list e watch nos nós, volumes persistentes, pods e classes de armazenamento do cluster, que lhes permitem ver detalhes sobre estes recursos.

kubectl

Para criar o cloud-console-reader ClusterRole 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

Em seguida, pode conceder esta função aos utilizadores quando configurar as suas políticas de autorização, conforme descrito na secção seguinte.

Crie e aplique políticas de RBAC necessárias

O exemplo seguinte mostra como criar e aplicar as políticas de RBAC necessárias. A forma mais simples de o fazer é usar a CLI gcloud para gerar e aplicar as políticas adequadas para si. Em alternativa, se preferir, pode criar um ficheiro de política RBAC e aplicá-lo com kubectl.

gcloud

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

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 o seguinte:

  • MEMBERSHIP_NAME: o nome usado para representar exclusivamente o cluster na respetiva frota. Pode saber como verificar o nome da subscrição do cluster em Obtenha o estado da subscrição da frota.
  • ROLE: a função do Kubernetes que quer conceder aos utilizadores no cluster, por exemplo, clusterrole/cluster-admin, clusterrole/cloud-console-reader ou role/mynamespace/namespace-reader. Esta função já tem de existir antes de executar o comando.
  • USERS: os endereços de email dos utilizadores (contas de utilizador ou contas de serviço) aos quais quer conceder as autorizações, como uma lista separada por vírgulas. Por exemplo: --users=dana@example.com,test-acct@test-project.iam.gserviceaccount.com.
  • PROJECT_ID: o ID do projeto onde o cluster está registado.
  • KUBECONFIG_PATH: o caminho do ficheiro local onde o kubeconfig que contém uma entrada para o cluster está armazenado. Na maioria dos casos, é $HOME/.kube/config.
  • KUBECONFIG_CONTEXT: o contexto do cluster, tal como aparece no ficheiro kubeconfig. Pode obter o contexto atual na linha de comandos executando kubectl config current-context. Quer use o contexto atual ou não, certifique-se de que funciona para aceder ao cluster executando o seguinte comando:

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

Depois de executar gcloud container fleet memberships generate-gateway-rbac, vê algo semelhante ao seguinte no final do resultado, que é truncado 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.

Este é o contexto para aceder ao cluster através do gateway Connect.

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

kubectl

O exemplo seguinte mostra como criar políticas adequadas para um utilizador (dana@example.com) e uma conta de serviço (test@example-project.iam.gserviceaccount.com), concedendo-lhes ambos autorizações cluster-admin no cluster e guardando o ficheiro de política como /tmp/gateway-rbac.yaml. As políticas são, em seguida, 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:
  - dana@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: dana@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

Pode saber mais sobre como especificar autorizações RBAC em Usar autorização RBAC.

Suporte dos VPC Service Controls

Os VPC Service Controls oferecem uma camada adicional de defesa de segurança para Google Cloud serviços que é independente da gestão de identidade e de acesso (IAM). Embora a IAM permita um controlo de acesso baseado na identidade detalhado, os VPC Service Controls permitem uma segurança de perímetro baseada no contexto mais ampla, incluindo o controlo da saída de dados no perímetro. Por exemplo, pode especificar que apenas determinados projetos podem aceder aos seus dados do BigQuery. Pode saber mais sobre como o VPC Service Controls funciona para proteger os seus dados na vista geral do VPC Service Controls.

Pode usar os VPC Service Controls com a gateway Connect para maior segurança dos dados, depois de garantir que é possível aceder às APIs necessárias para usar a gateway a partir do perímetro de serviço especificado.

O que se segue?