Confiança de clusters

Nesta página, você verá uma descrição da confiança nos cluster 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 do 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 kubelet para o servidor da API, essa solicitação é autenticada e criptografada usando TLS mútuo.
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 instância, essa solicitação é autenticada e criptografada usando o 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 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 mestre da API é assinado pela CA raiz do cluster. Cada cluster executa a própria CA, de modo que, se a CA de um cluster ficar comprometida, nenhuma outra será 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 mestre é executado. Todos os códigos em execução nas VMs mestres, ou que tenham acesso a metadados de computação dessas VMs, podem assinar certificados como essa CA. Mesmo que o etcd em um cluster fosse comprometido, a CA não é compartilhada entre os clusters, por isso 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

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Documentação do Kubernetes Engine