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 exemplos de tarefas referenciados no conteúdo do Google Cloud , consulte Papéis e tarefas de usuário comuns do GKE Enterprise.
Antes de ler esta página, confira se você conhece os seguintes conceitos:
Comunicação intracluster
O GKE aplica vários mecanismos de segurança ao tráfego entre componentes do cluster, da seguinte maneira:
Tráfego entre o plano de controle e os nós: 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 de proxy da Konnectivity. As solicitações enviadas pelo plano de controle são autenticadas e protegidas por TLS. 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 (mTLS).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.
Tráfego entre nós: os nós são VMs do Compute Engine. As conexões entre nós dentro da rede de produção Google Cloud são autenticadas e criptografadas. Para detalhes, consulte a seção entre VMs do whitepaper Criptografia em trânsito.
Tráfego 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 Google Cloud Criptografia e autenticação de rede virtual.
É 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.
Tráfego entre componentes do plano de controle: o tráfego entre vários componentes executados no plano de controle é autenticado e criptografado usando TLS. O tráfego nunca deixa uma rede de propriedade do Google protegida por firewalls.
Raiz de confiança
O GKE tem a seguinte configuração:
- A Autoridade de Certificação (AC) raiz do cluster é usada para validar os certificados de cliente do servidor de API e dos kubelets. Ou seja, os planos de controle e nós têm a mesma raiz de confiança. Qualquer kubelet no pool de nós do cluster pode solicitar um
certificado dessa CA usando a API
certificates.k8s.io, enviando uma solicitação de assinatura de certificado (em inglês). A CA raiz tem um ciclo de vida limitado, conforme descrito na seção Ciclo de vida da CA raiz do cluster. - Em clusters que executam instâncias de banco de dados etcd nas VMs do plano de controle, uma CA de etcd peer separada por cluster é usada para estabelecer confiança entre instâncias etcd.
- Em todos os clusters do GKE, uma CA da API etcd separada é usada para estabelecer a confiança entre o servidor da API Kubernetes e a API etcd.
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
DEGRADEDsete 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.
Armazenamento de estado do cluster
Os clusters do GKE armazenam o estado dos objetos da API Kubernetes como pares de chave-valor em um banco de dados. O servidor da API Kubernetes no seu plano de controle interage com esse banco de dados usando a API etcd. O GKE usa uma das seguintes tecnologias para executar o banco de dados de estado do cluster:
- Etcd: o cluster usa instâncias etcd que são executadas nas VMs do plano de controle.
- Spanner: o cluster usa um banco de dados Spanner que é executado fora das VMs do plano de controle.
Independentemente da tecnologia de banco de dados usada por um cluster, todos os clusters do GKE atendem à API etcd no plano de controle. Para criptografar o tráfego que envolve o banco de dados de estado do cluster, o GKE usa uma ou ambas as seguintes ACs por cluster:
- CA da API etcd: usada para assinar certificados de tráfego de e para os endpoints da API etcd. Uma CA da API etcd é executada em todos os clusters do GKE.
- CA de peer do etcd: usada para assinar certificados de tráfego entre instâncias do banco de dados do etcd no plano de controle. Uma AC de peer etcd é executada em qualquer cluster que usa bancos de dados etcd. Os clusters que usam bancos de dados do Spanner não usam a AC de peer do etcd.
As chaves raiz da CA da API etcd são distribuídas para os metadados de cada instância do Compute Engine em que o plano de controle é executado. A CA da API etcd não é compartilhada entre clusters.
Os certificados de CA do etcd são válidos por cinco anos. O GKE alterna esses certificados automaticamente antes que eles expirem.
Rotação de 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.