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
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 okubectl
, 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.
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çãoserviceusage.services.enable
ativada ou conceder-lheroles/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 okubectl
para gerir o cluster. Esta função inclui a autorizaçãogkehub.gateway.stream
, que permite aos utilizadores executar os comandosattach
,cp
eexec
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 clusterkubeconfigs
.
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 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
.
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 aokubectl
. 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, substituaMEMBER
pelo endereço de email ou pela conta de serviço do utilizador 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 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
ouclusterrole/cloud-console-reader
, ou uma função ao nível do espaço de nomes, comorole/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
ourole/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?
- Saiba como usar a gateway Connect para estabelecer ligação a clusters a partir da linha de comandos.
- Veja um exemplo de como usar o gateway Connect como parte da sua automatização de DevOps no nosso tutorial Integração com o Cloud Build.