Nesta página, você verá uma descrição da confiança nos clusters do Google Kubernetes Engine (GKE), incluindo como planos de controle e nós autenticam solicitações.
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 em clusters públicos, a solicitação é enviada por um túnel do proxy Konnectivity. As solicitações para nós em clusters particulares são enviadas por peering de VPC. 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, como 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:
- A Autoridade de Certificação raiz do cluster é usada para validar os certificados de cliente do servidor de APIs e do 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. - Uma CA de etcd separada por cluster é usada para validar os certificados do 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.
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.