O que usa o Connect

Última modificação do tópico: 4 de novembro de 2021

Ao registrar os clusters do Kubernetes no Google Cloud usando o Connect, uma conexão de longa duração autenticada e criptografada é estabelecida entre os clusters e o plano de controle do Google Cloud. A conexão mostra informações sobre clusters no console do Google Cloud e permite gerenciar e implantar configurações e recursos para clusters usando componentes e recursos do GKE Enterprise, como o Config Management.

Neste tópico, descrevemos a natureza da conexão entre o Google Cloud e o Connect. Além disso, fornecemos detalhes sobre os controladores do lado do Google Cloud que operam nos clusters via Connect.

Sobre a conexão entre o Google Cloud e o Connect

Conforme descrito no tópico Recursos de segurança, somente o plano de controle do Google Cloud faz solicitações por conexão para cada cluster conectado (por exemplo, ao servidor de API de um cluster). e o cluster envia as respostas ao plano de controle. Serviços e recursos de cluster não podem iniciar solicitações para o plano de controle por meio do Connect. A conexão permite que usuários autorizados e a automação do Google alcancem e autentiquem em clusters.

Por exemplo, o Connect permite que o console do Google Cloud receba informações sobre cargas de trabalho e serviços. Ou então, permite que o Config Management instale ou atualize o agente do Connect no cluster e observe o status da sincronização. O Connect também permite que o agente de medição observe o número de vCPUs em um cluster conectado.

O Connect não fornece transporte de dados para imagens de contêiner, balanceamento de carga, conexões de banco de dados, Logging ou Monitoring. Você precisa estabelecer conectividade para elas em paralelo por meio dos próprios mecanismos.

Acesso de usuário do console do Google Cloud aos clusters pelo Connect

Depois que os usuários da sua organização fizerem login em um cluster por meio do console do Google Cloud, eles terão permissões específicas do cluster determinadas pelos controles de acesso baseado em papéis (RBAC, na sigla em inglês) atribuídos a deles. O cluster (não o Connect) aplica as permissões. Os registros padrão do Kubernetes permitem auditar as ações que cada usuário executou no gerenciamento de um cluster.

A tabela a seguir mostra quais partes do console do Google Cloud permitem que os usuários interajam com clusters por meio do Connect.

Seção do console do Google Cloud O que os usuários podem fazer
GKE Enterprise Gerenciar clusters e cargas de trabalho registrados na frota gerenciar componentes do GKE Enterprise.
Kubernetes Engine Gerenciar clusters e cargas de trabalho registradas pela frota.
Knative serving Crie, implante e gerencie serviços e aplicativos.
Marketplace Implante e gerencie aplicativos de terceiros.

Acesso do controlador no lado do Google Cloud a clusters por meio do Connect

Os controladores do Google Cloud acessam um cluster a partir do plano de controle do Google Cloud usando o Connect Agent. Esses controladores fornecem gerenciamento e automação para a funcionalidade que você ativa nos clusters. Por exemplo, o Config Management tem um controlador do Google Cloud que ajuda a direcionar o ciclo de vida dos agentes no cluster e fornece uma IU para configurar e visualizar o status do Config Management em execução em vários clusters.

Diferentes controladores acessam clusters usando identidades distintas, e é possível auditar as atividades de cada controlador nos registros de auditoria do Kubernetes.

A tabela a seguir resume como os controladores do Google Cloud operam no Connect. A tabela destaca detalhes importantes sobre os controladores: as permissões de que precisam, os códigos nos registros de auditoria do Kubernetes e se eles podem ser desativados ou não.

Desativar um componente nesse contexto significa desativá-lo completamente, sem partes individuais dele para serem usadas nos clusters.

Component Name Pode ser desativado? Papel de cluster/permissões do RBAC Descrição ID nos registros de auditoria do cluster
Autorizador de recursos Não (ativado por padrão) cluster-admin

O Autorizador de recursos adiciona o RBAC a componentes compatíveis com a frota ou, que operam em clusters do Kubernetes, garantindo que cada um tenha apenas as permissões específicas necessárias para executar as funções.

Não é possível desativar o Autorizado do recurso se houver assinaturas registradas no projeto.

Consulte Autorização de recursos em uma frota para mais informações.

service-project-number@gcp-sa-gkehub.iam.gserviceaccount.com
Gerenciamento de configurações Sim (desativado por padrão) cluster-admin

O controlador do Config Management gerencia os próprios agentes no cluster e fornece uma IU que mostra o status do Config Management em todos os clusters de uma frota.

O controlador instala os componentes no cluster e cria uma conta de serviço local com as permissões apropriadas para implantar todos os tipos de configurações do Kubernetes em nome dos usuários. Quando não instala ou gerencia componentes no cluster, o controlador do Config Management lê informações de status do agente no cluster.

service-project-number@gcp-sa-acm.iam.gserviceaccount.com
Medição de uso Não (ativado por padrão) Consulte Definição do RBAC

O controlador de medição lê informações básicas sobre os clusters conectados para fornecer serviços de faturamento.

Esse controlador precisa das permissões para:

  • medidor com base na capacidade da vCPU do nó.
  • Assista e exclua o recurso personalizado metering.gke.io/usagerecords.
  • Crie e atualize o recurso personalizado anthos.gke.io/entitlements.

Não é possível desativar a medição, desde que haja assinaturas registradas no projeto.

service-project-number@gcp-sa-mcmetering.iam.gserviceaccount.com

RBAC para componentes específicos que operam por meio do Connect

As definições da API a seguir mostram permissões de controle de acesso para diferentes recursos do componente que operam por meio do Connect.

Métricas de uso do RBAC no Connect

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    hub.gke.io/owner-feature: metering
    hub.gke.io/project: [PROJECT_ID]
  name: metering
  selfLink: /apis/rbac.authorization.k8s.io/v1/clusterroles/metering
rules:
- apiGroups:
  - ""
  resources:
  - nodes
  verbs:
  - get
  - watch
  - list
- apiGroups:
  - metering.gke.io
  resources:
  - usagerecords
  verbs:
  - get
  - list
  - watch
  - delete
- apiGroups:
  - anthos.gke.io
  resources:
  - entitlements
  verbs:
  - create
  - delete
  - get
  - list
  - update
  - watch
- apiGroups:
  - apiextensions.k8s.io
  resources:
  - customresourcedefinitions
  verbs:
  - create
  - list
  - watch
- apiGroups:
  - apiextensions.k8s.io
  resourceNames:
  - entitlements.anthos.gke.io
  resources:
  - customresourcedefinitions
  verbs:
  - get