Confiança de clusters

Nesta página, você verá uma descrição da confiança nos clusters do Google Kubernetes Engine, incluindo como os planos de controle (mestres) e os 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 ao nó, por exemplo, registros do kubectl, essa solicitação é enviada por um túnel SSH e, além disso, protegida por TLS, fornecendo autenticação, integridade e criptografia. Quando um nó envia uma solicitação ao plano de controle, por exemplo, 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

A comunicação de um nó com outro é possível como parte de uma carga de trabalho específica. Quando o nó envia uma solicitação para outro, essa solicitação é autenticada e será criptografada se a conexão atravessar uma barreira física controlada pelo Google. Observe que nenhum componente do Kubernetes exige a comunicação de nó para nó. Para saber mais, leia o artigo Criptografia em trânsito.

Entre pods

A comunicação de um pod com outro é possível como parte de uma carga de trabalho específica. Quando o pod envia uma solicitação para outro, essa solicitação não é autenticada nem criptografada. Observe que nenhum componente do Kubernetes exige a comunicação entre pods. É possível restringir o tráfego entre pods com uma política de rede. Para criptografar esse tráfego, use uma malha de serviço, como o Istio, ou implemente a criptografia da camada de aplicativos.

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

A comunicação ocorre inteiramente pelo localhost e não é autenticada nem criptografada.

Raiz de confiança

O GKE está configurado desta maneira:

Servidor da API e kubelets

O servidor da API e o kubelets dependem da CA raiz do cluster do Kubernetes 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 ficasse comprometida, nenhuma outra CA de cluster seria afetada.

Um serviço interno do Google 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. Observe que esse segredo compartilhado pode ser acessado por pods, a menos que a ocultação de metadados esteja ativada.

O servidor da API e os certificados do kubelet são válidos por cinco anos, mas podem ser alternados manualmente antes, por meio de uma rotação de credenciais.

etcd

O etcd depende de uma CA do etcd separada por cluster para a confiança no GKE.

As chaves raiz da CA do etcd são distribuídas para os metadados de cada VM 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 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