Confiança de clusters

Esta página descreve o modelo de confiança nos clusters do Google Kubernetes Engine (GKE), incluindo a comunicação dentro dos clusters e como as solicitações são autenticadas para componentes como planos de controle.

Este documento é destinado a especialistas em segurança que querem entender o modelo de confiança do cluster do GKE. Para saber mais sobre papéis comuns e tarefas de exemplo referenciados no conteúdo do Google Cloud, consulte Tarefas e funções de usuário comuns do GKE Enterprise.

Antes de ler esta página, confira se você conhece os seguintes conceitos:

Comunicação intracluster

Há muitas conexões em um cluster para comunicação entre os componentes do Kubernetes.

Plano de controle para nó

O plano de controle se comunica com um nó para gerenciar contêineres. Quando o plano de controle envia uma solicitação, por exemplo, kubectl logs, para nós, a solicitação é enviada por um túnel do proxy Konnectivity. As solicitações enviadas pelo plano de controle são protegidas com TLS, fornecendo autenticação, integridade e criptografia. Quando um nó envia uma solicitação ao plano de controle, por exemplo, do kubelet para o servidor da API, essa solicitação é autenticada e criptografada usando TLS mútuo.

Todos os clusters recém-criados e atualizados usam o TLS 1.3 para comunicação de plano a nó. O TLS 1.2 é a versão mínima compatível com o plano de controle para a comunicação de nós.

Entre nós

Nós são VMs do Compute Engine para as quais as conexões dentro da rede de produção do Google Cloud é autenticada e criptografada. Para detalhes, consulte a seção entre VMs do artido de criptografia em trânsito.

Entre pods

Quando um pod envia uma solicitação para outro, esse tráfego não é autenticado por padrão. O GKE criptografa o tráfego entre pods em diferentes nós na camada de rede. O tráfego entre pods no mesmo nó não é criptografado por padrão. Para detalhes sobre a criptografia da camada de rede, consulte Criptografia e autenticação de rede virtual do Google Cloud.

É possível restringir o tráfego entre pods com uma NetworkPolicy. Além disso, é possível criptografar todo o tráfego entre pods, inclusive no mesmo nó, usando uma malha de serviço como o Cloud Service Mesh ou outro método de criptografia da camada do aplicativo.

Entre etcds

A comunicação de uma instância do etcd com outra é possível para manter o estado atualizado. Quando uma instância do etcd envia uma solicitação para outra, ela é autenticada e criptografada usando TLS mútuo. O tráfego nunca deixa uma rede de propriedade do GKE protegida por firewalls.

Plano de controle para o etcd

Esta comunicação é criptografada usando TLS mútuo.

Raiz de confiança

O GKE tem a seguinte configuração:

Servidor da API e kubelets

O servidor da API e o kubelets dependem da CA raiz do cluster para a confiança. No GKE, o certificado da API do plano de controle é assinado pela CA raiz do cluster. Cada cluster executa sua própria CA, de modo que se a CA de um cluster for comprometida, nenhuma outra CA de cluster será afetada.

Um serviço interno gerencia as chaves raiz dessa CA, que não podem ser exportadas. Esse serviço aceita solicitações e assinatura de certificado, incluindo as provenientes do kubelets em cada cluster do GKE. Mesmo que o servidor da API em um cluster fosse comprometido, a CA não seria comprometida, portanto, nenhum outro cluster seria afetado.

Cada nó no cluster é injetado com uma senha secreta na criação, que ele pode usar para enviar solicitações de assinatura de certificado para a CA raiz do cluster e receber certificados do cliente do kubelet. Em seguida, esses certificados são usados pelo kubelet para autenticar as solicitações para o servidor da API. Esta senha secreta pode ser acessada por pods no nó, a menos que você ative Nós protegidos do GKE ou a federação de identidade da carga de trabalho para GKE.

Ciclo de vida da CA raiz do cluster

A CA raiz do cluster tem um ciclo de vida limitado. Após esse período, todos os certificados assinados pela CA expirada são inválidos. Verifique a data de expiração aproximada da CA do cluster seguindo as instruções em Verificar ciclo de vida da credencial.

Faça a rotação manual das suas credenciais antes que a CA raiz atual expire. Se a CA expirar e você não alternar suas credenciais, o cluster poderá entrar em um estado irrecuperável. O GKE tem os seguintes mecanismos para tentar evitar clusters irrecuperáveis:

  • Seu cluster entra em um estado DEGRADED sete dias antes da expiração da CA

  • O GKE tenta uma rotação automática de credenciais 30 dias antes da expiração da CA. Essa rotação automática ignora as janelas de manutenção e pode causar interrupções conforme o GKE recria os nós para usar novas credenciais. Clientes externos, como o kubectl em ambientes locais, não funcionarão até que você os atualize para usar as novas credenciais.

Para saber como executar uma rotação, consulte Alternar as credenciais do cluster.

etcd

No GKE, o etcd depende de uma CA do etcd separada por cluster para a confiança.

As chaves raiz da CA do etcd são distribuídas para os metadados de cada máquina virtual (VM, na sigla em inglês) em que o plano de controle é executado. Qualquer código executado em VMs do plano de controle ou com acesso para calcular metadados dessas VMs pode assinar certificados como essa CA. Mesmo que o etcd em um cluster esteja comprometido, a CA não é compartilhada entre clusters. Portanto, nenhum outro cluster seria afetado.

Os certificados de etcd são válidos por cinco anos.

Como fazer a rotação dos certificados

Para alternar todos os certificados do servidor da API e do kubelet do cluster, faça uma rotação de credenciais. Não é possível acionar uma rotação dos certificados do etcd, isso é gerenciado no GKE.

Próximas etapas