Pré-requisitos para registrar um cluster

Nesta página, descrevemos os pré-requisitos e requisitos para registrar um cluster do Kubernetes com o Google Cloud, incluindo a configuração de rede, do Google Cloud e do Kubernetes, bem como os requisitos de recursos do agente do Connect.

Garantir conectividade de rede

Para registrar seu cluster, verifique se os domínios abaixo estão acessíveis com seu cluster do Kubernetes:

  • cloudresourcemanager.googleapis.com resolve os metadados referentes ao projeto do Google Cloud a que o cluster está sendo conectado.
  • oauth2.googleapis.com para receber tokens OAuth de curta duração para operações de agente em gkeconnect.googleapis.com.
  • gkeconnect.googleapis.com para estabelecer o canal usado para receber solicitações do Google Cloud e enviar respostas.
  • gkehub.googleapis.com para criar recursos de assinatura do hub do Google Cloud que correspondam ao cluster que você está conectando ao Google Cloud.
  • www.googleapis.com para autenticar tokens de serviço das solicitações de serviço recebidas do Google Cloud.
  • gcr.io para extrair a imagem do agente do GKE Connect.

Se você estiver usando um proxy para o Connect, também precisará atualizar a lista de permissões do proxy com esses domínios.

Se você usa o gcloud para registrar o cluster do Kubernetes, esses domínios também precisam ser acessados no ambiente em que você executa os comandos do gcloud.

Como usar VPC Service Controls

Se você quiser usar o VPC Service Controls para aumentar a segurança dos dados no aplicativo, será preciso garantir que os seguintes serviços estejam no perímetro do serviço:

  • API Resource Manager (cloudresourcemanager.googleapis.com)
  • API GKE Connect (gkeconnect.googleapis.com)
  • API GKE Hub (gkehub.googleapis.com)

Também é necessário configurar a conectividade particular para acessar as APIs relevantes. Saiba como fazer isso em Configurar a conectividade particular.

Configuração e definição do Google Cloud

Instale o Cloud SDK

Instale o SDK do Cloud, que inclui o gcloud, a interface de linha de comando (CLI) do Google Cloud.

Autorize o gcloud a acessar o Google Cloud

Depois de instalar o SDK do Cloud, execute o seguinte comando para fazer login no Google Cloud:

gcloud auth login

Instalar o gcloud beta (opcional)

Instale o componente gcloud beta, se você planeja testar recursos Alfa ou Beta do Connect:

 gcloud components install beta 

Conceder os papéis necessários do IAM ao usuário que registra o cluster

Ter papéis/proprietário em seu projeto oferece controle total e permite concluir as tarefas de registro.

Se você não tiver papéis/proprietário do projeto, precisará receber papéis específicos do IAM antes de conectar clusters ao Google. Consulte Conectar papéis do IAM.

Os papéis do IAM a seguir garantem que você possa se registrar e se conectar a clusters:

  • roles/gkehub.admin
  • roles/iam.serviceAccountAdmin
  • roles/iam.serviceAccountKeyAdmin
  • roles/resourcemanager.projectIamAdmin

gcloud

gcloud projects add-iam-policy-binding [HUB_PROJECT_ID] \
 --member user:[GCP_EMAIL_ADDRESS] \
 --role=roles/gkehub.admin \
 --role=roles/iam.serviceAccountAdmin \
 --role=roles/iam.serviceAccountKeyAdmin \
 --role=roles/resourcemanager.projectIamAdmin

onde:

  • [HUB_PROJECT_ID] é o ID do projeto do Google Cloud em que você quer registrar clusters. Saiba como encontrar esse valor.
  • [GCP_EMAIL_ADDRESS] é o registro de conta usado pelos usuários para fazer login no Google Cloud.

Para saber mais sobre como conceder papéis do IAM, consulte Como conceder, alterar e revogar o acesso a recursos na documentação do IAM.

Ativar as APIs necessárias no projeto

É preciso ativar as seguintes APIs no projeto do Google Cloud:

  • container.googleapis.com
  • gkeconnect.googleapis.com
  • gkehub.googleapis.com
  • cloudresourcemanager.googleapis.com
  • stackdriver.googleapis.com
  • meshconfig.googleapis.com
  • meshtelemetry.googleapis.com
  • meshca.googleapis.com

Os pods no cluster precisam ser capazes de acessar os endereços googleapis.com e gkeconnect.googleapis.com, seja diretamente ou usando um servidor proxy configurado.

Os proprietários que não são do projeto precisam receber a permissão serviceusage.services.enable antes de ativar APIs.

Para ativar essas APIs, execute o seguinte comando:

gcloud

gcloud services enable \
 --project=[HUB_PROJECT_ID] \
 container.googleapis.com \
 gkeconnect.googleapis.com \
 gkehub.googleapis.com \
 cloudresourcemanager.googleapis.com

onde:

Conceder papéis somente leitura a outros usuários

Os usuários autenticados com os papéis a seguir podem visualizar clusters de usuário registrados no Console do Cloud. Estes papéis fornecem acesso somente leitura:

  • roles/gkehub.viewer
  • roles/container.viewer

Por exemplo, para conceder ao usuário os papéis roles/gkehub.viewer e roles/container.viewer, execute o comando a seguir:

gcloud

gcloud projects add-iam-policy-binding [HUB_PROJECT_ID] \
 --member user:[USER_EMAIL_ADDRESS] \
 --role roles/gkehub.viewer \
 --role=roles/container.viewer

onde:

  • [HUB_PROJECT_ID] é o ID do projeto do Google Cloud em que você quer registrar clusters. Saiba como encontrar esse valor.
  • [USER_EMAIL_ADDRESS] é o endereço de e-mail de usuários autenticados.

Criar uma conta de serviço do Google Cloud usando gcloud

Um arquivo JSON contendo credenciais de Conta de serviço do Google Cloud é necessário para registrar manualmente um cluster. Para seguir o princípio do menor privilégio, recomendamos que você crie uma conta de serviço distinta para cada cluster do Kubernetes registrado e vincule os papéis do IAM a ela no cluster correspondente.

Para criar esse arquivo, execute as seguintes etapas:

gcloud

Execute o seguinte comando para criar uma conta de serviço:

gcloud iam service-accounts create [SERVICE_ACCOUNT_NAME] --project=[HUB_PROJECT_ID]

Liste todas as contas de serviço de um projeto executando o seguinte comando:

gcloud iam service-accounts list --project=[HUB_PROJECT_ID]

Se você estiver criando uma conta de serviço distinta para cada cluster do Kubernetes registrado, vincule o papel do GKE gkehub.connect à conta de serviço do cluster correspondente a uma Condição do IAM no nome da assinatura do cluster:

MEMBERSHIP_NAME=[MEMBERSHIP_NAME]
HUB_PROJECT_ID=[HUB_PROJECT_ID]
SERVICE_ACCOUNT_NAME=[SERVICE_ACCOUNT_NAME]
gcloud projects add-iam-policy-binding ${HUB_PROJECT_ID} \
 --member="serviceAccount:${SERVICE_ACCOUNT_NAME}@${HUB_PROJECT_ID}.iam.gserviceaccount.com" \
 --role="roles/gkehub.connect" \
 --condition "expression=resource.name == \
'projects/${HUB_PROJECT_ID}/locations/global/memberships/${MEMBERSHIP_NAME}',\
title=bind-${SERVICE_ACCOUNT_NAME}-to-${MEMBERSHIP_NAME}"

Caso contrário, vincule o papel à conta de serviço para todos os clusters no projeto sem a condição.

HUB_PROJECT_ID=[HUB_PROJECT_ID]
gcloud projects add-iam-policy-binding ${HUB_PROJECT_ID} \
 --member="serviceAccount:[SERVICE_ACCOUNT_NAME]@${HUB_PROJECT_ID}.iam.gserviceaccount.com" \
 --role="roles/gkehub.connect"

Faça o download do arquivo JSON da chave privada da conta de serviço. Você usa esse arquivo ao registrar um cluster:

HUB_PROJECT_ID=[HUB_PROJECT_ID]
gcloud iam service-accounts keys create [LOCAL_KEY_PATH] \
  --iam-account=[SERVICE_ACCOUNT_NAME]@${HUB_PROJECT_ID}.iam.gserviceaccount.com \
  --project=${HUB_PROJECT_ID}

onde:

  • [HUB_PROJECT_ID] é o ID do projeto do Google Cloud em que você quer registrar clusters. Saiba como encontrar esse valor.
  • [SERVICE_ACCOUNT_NAME] é o nome de exibição escolhido para a conta de serviço.
  • [MEMBERSHIP_NAME] é o nome da assinatura que você escolhe para representar o cluster de maneira exclusiva enquanto o registra.
  • [LOCAL_KEY_PATH] é um caminho de arquivo local onde você quer salvar a chave privada da conta de serviço, um arquivo JSON. Recomendamos que você nomeie o arquivo usando o nome da conta de serviço e o ID do projeto, como: /tmp/creds/[SERVICE_ACCOUNT_NAME]-[HUB_PROJECT_ID].json

Como registrar um cluster do GKE em um projeto diferente

Na primeira vez que você registrar um cluster do GKE no projeto (GKE_PROJECT) para um projeto diferente (HUB_PROJECT), primeiro conceda as permissões necessárias. A conta de serviço padrão HUB_PROJECT gcp-sa-gkehub requer o papel Agente de serviço do hub no projeto GKE_PROJECT. O Agente de serviço do hub é um papel do IAM que concede à conta de serviço as permissões para gerenciar recursos de cluster.

Confirme se gcp-sa-gkehub tem o papel necessário usando a ferramenta gcloud ou o Console do Cloud. Se o comando ou o painel não exibe gcp-sa-gkehub, isso significa que o papel necessário está ausente. Se você vir gcp-sa-gkehub, ele terá o formato service-[HUB-PROJECT-NUMBER]@gcp-sa-gkehub.iam.gserviceaccount.com.

gcloud

Execute este comando:

gcloud projects get-iam-policy [GKE_PROJECT_ID]

Para conceder o papel gcp-sa-gkehub Agente de serviço do Hub, primeiro é necessário garantir que a conta de serviço padrão do Hub existe. Se você já registrou clusters neste projeto antes, a conta de serviço já deve existir.

Para criar gcp-sa-gkehub, execute o seguinte comando:

gcloud beta services identity create --service=gkehub.googleapis.com --project=[HUB_PROJECT_ID]

Esse comando gera o resultado a seguir:

Service identity created: service-[HUB_PROJECT_NUMBER]@gcp-sa-gkehub.iam.gserviceaccount.com

Quando a conta de serviço gcp-sa-gkehub existir, execute o seguinte comando para conceder a ela o papel roles/gkehub.serviceAgent:

GKE_PROJECT_ID=[GKE_PROJECT_ID]
HUB_PROJECT_ID=[HUB_PROJECT_ID]
HUB_PROJECT_NUMBER=$(gcloud projects describe "${HUB_PROJECT_ID}" --format "value(projectNumber)")
gcloud projects add-iam-policy-binding "${HUB_PROJECT_ID}" \
--member "serviceAccount:service-${HUB_PROJECT_NUMBER}@gcp-sa-gkehub.iam.gserviceaccount.com" \
--role roles/gkehub.serviceAgent
gcloud projects add-iam-policy-binding "${GKE_PROJECT_ID}" \
--member "serviceAccount:service-${HUB_PROJECT_NUMBER}@gcp-sa-gkehub.iam.gserviceaccount.com" \
--role roles/gkehub.serviceAgent

onde:

  • [GKE_PROJECT_ID] é o ID do projeto do Google Cloud do cluster do GKE.
  • [HUB_PROJECT_ID] é o ID do projeto do Google Cloud em que você quer registrar clusters. Saiba como encontrar esse valor.

Para confirmar se a vinculação de papel foi concedida:

  gcloud projects get-iam-policy [GKE_PROJECT_ID]
  

Se o nome da conta de serviço estiver com a função gkehub.serviceAgent, a vinculação de papel foi concedida. Exemplo:

  - members:
    - serviceAccount:service-[HUB_PROJECT_NUMBER]@gcp-sa-gkehub.iam.gserviceaccount.com
    role: roles/gkehub.serviceAgent

Configuração e definição do Kubernetes

Instalar o kubectl

.

Recomendamos instalar o kubectl com o SDK do Cloud.

Para verificar a versão do kubectl:

kubectl version

A versão do cliente é indicada por "gitVersion" da saída.

Para instalar o kubectl:

gcloud components install kubectl

Conceder o papel RBAC de administrador do cluster ao usuário que o registra

O ClusterRole é um controle de acesso baseado em papéis (RBAC, na sigla em inglês) do administrador do cluster. Ele concede a você as permissões necessárias para conectar os clusters ao Google.

Se você criou o cluster, é provável que já tenha esse papel. Para verificar, execute o seguinte comando:

kubectl auth can-i '*' '*' --all-namespaces

Se você ou outro usuário precisar do papel, crie um recurso "ClusterRoleBinding" no cluster:

kubectl create clusterrolebinding [BINDING_NAME] --clusterrole cluster-admin --user [USER] 

onde:

  • [BINDING_NAME] é um nome que você escolhe para o recurso "ClusterRoleBinding";
  • [USER] é a identidade usada para se autenticar no cluster.

Para mais informações sobre o papel de administrador do cluster, consulte a documentação do Kubernetes.

Como usar controles de admissão

Como parte do registro do cluster no Google Cloud, o agente do Connect é instalado no cluster. Dependendo da plataforma de contêiner e do controlador de admissão, talvez seja necessário criar políticas de admissão que permitam a instalação do agente.

Políticas de segurança de pods (PSP)

Uma PodSecurityPolicy é um recurso controlador de admissão opcional que valida solicitações para criar e atualizar pods no cluster. As políticas de segurança de pods são aplicadas somente quando o plug-in do controlador de admissão da PSP está ativado.

Se o cluster usar o plug-in do controlador de admissão da PSP, não será necessário criar políticas adicionais para usar o agente do Connect, porque políticas específicas do agente do Connect e os papéis do RBAC são instalados automaticamente como parte do registro do cluster.

Use os seguintes comandos para finalizar a política de PSP e RBACs instalados:

$ kubectl get psp | grep connect
$ kubectl get role,rolebindings -n gke-connect | grep psp

Restrições de contexto de segurança (SCC, na sigla em inglês)

Nos clusters OpenShift OKE e OKD, os administradores podem usar SCCs para controlar as permissões dos pods. Para permitir a instalação do agente do Connect no cluster, você precisa criar uma SCC personalizada.

A amostra de definição de SCC a seguir especifica o conjunto de condições que o agente do Connect precisa executar para ser aceito no cluster:

# Connect Agent SCC
apiVersion: v1
kind: SecurityContextConstraints
metadata:
  name: gke-connect-scc
allowPrivilegeEscalation: false
# This is redundant with non-root + disallow privilege escalation,
# but we provide it for defense in depth.
requiredDropCapabilities:
- ALL
runAsUser:
  type: MustRunAsNonRoot
seLinuxContext:
  type: RunAsAny
supplementalGroups:
  type: MustRunAs
  ranges:
  - min: 1
    max: 65535
fsGroup:
  type: MustRunAs
  ranges:
  - min: 1
    max: 65535
volumes:
- secret
readOnlyRootFilesystem: true
seccompProfiles:
- docker/default
users:
groups:
  # Grants all service accounts in the gke-connect namespace access to this SCC
  - system:serviceaccounts:gke-connect

Supondo que você salvou a definição de SCC como gke-connect-scc.yaml, use a ferramenta de linha de comando oc do OpenShift para criar a SCC gke-connect-scc para o cluster da seguinte maneira:

$ oc create -f gke-connect-scc.yaml

Para verificar se a SCC personalizada foi criada, execute o seguinte comando oc:

$ oc get scc | grep gke-connect-scc

Uso de recursos e requisitos

Normalmente, o agente do Connect instalado no registro usa 500 m de CPU e 200 Mi de memória. No entanto, esse uso pode variar dependendo do número de solicitações feitas ao agente por segundo e do tamanho dessas solicitações. Isso pode ser afetado por vários fatores, incluindo o tamanho do cluster, o número de usuários que acessam o cluster pelo Console do Cloud (quanto mais usuários e/ou cargas de trabalho, mais solicitações) e o número de recursos ativados pelo ambiente no cluster.

A seguir