Esta página descreve o modelo de confiança nos clusters do Google Kubernetes Engine (GKE), incluindo a comunicação nos clusters e como os pedidos são autenticados para componentes como planos de controlo.
Este documento destina-se a especialistas em segurança que querem compreender o modelo de confiança do cluster do GKE. Para saber mais acerca das funções comuns e das tarefas de exemplo que referimos no Trusted Cloud by S3NS conteúdo, consulte o artigo Funções e tarefas comuns de utilizadores do GKE.
Antes de ler esta página, certifique-se de que conhece o seguinte:
Comunicação intracluster
O GKE aplica vários mecanismos de segurança ao tráfego entre os componentes do cluster, da seguinte forma:
Tráfego entre o plano de controlo e os nós: o plano de controlo comunica com um nó para gerir contentores. Quando o plano de controlo envia um pedido (por exemplo,
kubectl logs) aos nós, o pedido é enviado através de um túnel de proxy de conetividade. Os pedidos que o plano de controlo envia são autenticados e protegidos por TLS. Quando um nó envia um pedido ao plano de controlo, por exemplo, do kubelet para o servidor da API, esse pedido é autenticado e encriptado através do TLS mútuo (mTLS).Todos os clusters criados e atualizados recentemente usam o TLS 1.3 para a comunicação do plano de controlo com o nó. O TLS 1.2 é a versão mínima suportada para a comunicação do plano de controlo com o nó.
Tráfego entre nós: os nós são VMs do Compute Engine. As ligações entre os nós na rede de produção do Trusted Cloud são autenticadas e encriptadas. Para mais detalhes, consulte a secção VM para VM do Livro Branco sobre a encriptação em trânsito.
Tráfego entre pods: quando um pod envia um pedido a outro pod, esse tráfego não é autenticado por predefinição. O GKE encripta o tráfego entre pods em nós diferentes na camada de rede. Por predefinição, o tráfego entre pods no mesmo nó não é encriptado. Para ver detalhes sobre a encriptação da camada de rede, consulte o artigo Trusted Cloud Encriptação e autenticação de rede virtual.
Pode restringir o tráfego de pod para pod com uma NetworkPolicy e pode encriptar todo o tráfego de pod para pod, incluindo o tráfego no mesmo nó, usando uma malha de serviço como a Cloud Service Mesh ou um método diferente de encriptação da camada de aplicação.
Tráfego entre componentes do plano de controlo: o tráfego entre vários componentes executados no plano de controlo é autenticado e encriptado através do TLS. O tráfego nunca sai de uma rede pertencente à Google protegida por firewalls.
Raiz de fidedignidade
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 controlo e os nós têm a mesma raiz de fidedignidade. Qualquer kubelet no conjunto de nós do cluster pode pedir um certificado a esta AC através da API
certificates.k8s.io, enviando um pedido de assinatura de certificado. A CA de raiz tem uma vida útil limitada, conforme descrito na secção Vida útil da CA de raiz do cluster. - Em clusters que executam instâncias da base de dados etcd nas VMs do plano de controlo, é usada uma CA de pares etcd separada por cluster para estabelecer confiança entre instâncias etcd.
- Em todos os clusters do GKE, é usada uma AC da API etcd separada para estabelecer confiança entre o servidor da API Kubernetes e a API etcd.
Servidor de API e kubelets
O servidor da API e os kubelets dependem da AC raiz do cluster para a confiança. No GKE, o certificado da API do plano de controlo é assinado pela CA de raiz do cluster. Cada cluster executa a sua própria AC, para que, se a AC de um cluster for comprometida, nenhuma outra AC de cluster seja afetada.
Um serviço interno gere as chaves raiz desta AC, que não são exportáveis. Este serviço aceita pedidos de assinatura de certificados, incluindo os dos kubelets em cada cluster do GKE. Mesmo que o servidor da API num cluster fosse comprometido, a AC não seria comprometida, pelo que nenhum outro cluster seria afetado.
Cada nó no cluster recebe um segredo partilhado no momento da criação, que pode usar para enviar pedidos de assinatura de certificados para a AC raiz do cluster e obter certificados de cliente kubelet. Estes certificados são, em seguida, usados pelo kubelet para autenticar os respetivos pedidos ao servidor da API. Este segredo partilhado é acessível pelos pods no nó, a menos que ative os nós do GKE protegidos ou a federação de identidade da carga de trabalho para o GKE.
Duração da CA de raiz do cluster
A CA de raiz do cluster tem uma duração limitada, após a qual todos os certificados assinados pela CA expirada são inválidos. Verifique a data de validade aproximada da AC do cluster seguindo as instruções em Verifique a duração das credenciais.
Deve rodar manualmente as suas credenciais antes de a AC raiz existente expirar. Se o CA expirar e não rodar as suas credenciais, o cluster pode entrar num estado irrecuperável. O GKE tem os seguintes mecanismos para tentar evitar clusters irrecuperáveis:
- O seu cluster entra num estado
DEGRADEDsete dias antes da expiração do CA O GKE tenta uma rotação automática de credenciais 30 dias antes da expiração da AC. Esta rotação automática ignora as janelas de manutenção e pode causar interrupções, uma vez que o GKE recria nós para usar novas credenciais. Os clientes externos, como o kubectl em ambientes locais, não funcionam até os atualizar para usarem as novas credenciais.
Para saber como fazer uma rotação, consulte o artigo Rode as credenciais do cluster.
Armazenamento do estado do cluster
Os clusters do GKE armazenam o estado dos objetos da API Kubernetes como pares de chave-valor numa base de dados. O servidor da API Kubernetes no seu plano de controlo interage com esta base de dados através da API etcd. O GKE usa uma das seguintes tecnologias para executar a base de dados de estado do cluster:
- etcd: o cluster usa instâncias etcd que são executadas nas VMs do plano de controlo.
- Spanner: o cluster usa uma base de dados Spanner que é executada fora das VMs do plano de controlo.
Independentemente da tecnologia de base de dados que um cluster usa, todos os clusters do GKE servem a API etcd no plano de controlo. Para encriptar o tráfego que envolve a base de dados de estado do cluster, o GKE usa uma ou ambas as seguintes ACs por cluster:
- AC da API etcd: usada para assinar certificados para tráfego de e para pontos finais da API etcd. Uma CA da API etcd é executada em todos os clusters do GKE.
- AC de pares do etcd: usada para assinar certificados para tráfego entre instâncias da base de dados etcd no plano de controlo. Uma CA de pares etcd é executada em qualquer cluster que use bases de dados etcd. Os clusters que usam bases de dados do Spanner não usam a CA de pares etcd.
As chaves de raiz da CA da API etcd são distribuídas aos metadados de cada instância do Compute Engine em que o plano de controlo é executado. A CA da API etcd não é partilhada entre clusters.
Os certificados da AC do etcd são válidos durante cinco anos. O GKE roda automaticamente estes certificados antes de expirarem.
Rotação de certificados
Para rodar todos os certificados do servidor de API e kubelet do cluster, faça uma rotação de credenciais. Não existe forma de acionar uma rotação dos certificados etcd. Esta ação é gerida por si no GKE.