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
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 instalarkubectl
, 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.
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ãoserviceusage.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 usarkubectl
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 recuperekubeconfigs
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 formatouser|serviceAccount:emailID
. Por exemplo:user:alice@example.com
serviceAccount:test_sa@example-project.iam.gserviceaccount.com
GATEWAY_ROLE
éroles/gkehub.gatewayAdmin
,roles/gkehub.gatewayReader
ouroles/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 akubectl
. 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, substituaMEMBER
pelo endereço de e-mail ou pela conta de serviço do usuário usando o formatouser|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
ouclusterrole/cloud-console-reader
, ou um papel no nível do namespace, comorole/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
ourole/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
- 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.