Confiança de clusters

Nesta página, você verá uma descrição da confiança nos clusters do Google Kubernetes Engine, incluindo como os 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.

Entre mestre e nó
O mestre se comunica com um nó para gerenciar contêineres. Quando o mestre envia uma solicitação ao nó, por exemplo, registros da kubectl, essa solicitação é enviada por um túnel SSH e, além disso, protegida por TLS não autenticado, proporcionando integridade e criptografia. Quando um nó envia uma solicitação ao mestre, como a kubelet para o servidor da API, essa solicitação é autenticada e criptografada usando TLS mútuo.
Entre nós
A comunicação entre nós é 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 entre nós. Para saber mais, leia o whitepaper criptografia em trânsito.
Entre pods
A comunicação entre pods é 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, essa solicitação é autenticada e criptografada usando TLS mútuo. O tráfego nunca deixa uma rede de propriedade do GKE protegida por firewalls.
Entre o mestre e o etcd
A comunicação ocorre inteiramente pelo host local e não é autenticada nem criptografada.

Raiz de confiança

O GKE está configurado desta maneira:

  • A Autoridade de Certificação (CA) raiz do cluster (em inglês) é usada para validar os certificados de cliente do servidor da API e de kubelets. Ou seja, mestres 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).
  • Uma CA de etcd separada por cluster é usada para validar os certificados do etcd.

Servidor da API e kubelets

O servidor da API e a kubelets dependem da CA raiz do cluster do Kubernetes para a confiança. No GKE, o certificado da API mestre é assinado pela CA raiz do cluster. Cada cluster executa sua própria CA, de modo que se a CA de um cluster fosse comprometida, nenhuma 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 de assinatura de certificado, incluindo as provenientes da 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 um secret compartilhado 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 da kubelet. Em seguida, esses certificados são usados pela kubelet para autenticar as solicitações para o servidor da API. Observe que o secret compartilhado pode ser acessado por pods, a menos que a ocultação de metadados esteja ativada.

O servidor da API e os certificados da 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 mestre é executado. Qualquer código executado em VMs mestres ou com acesso a metadados de computação 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 servidores da API e certificados da 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.

A seguir