Este documento aborda 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 pressupõe que tem conhecimentos sobre o seguinte:
Este documento destina-se a especialistas de segurança que pretendem compreender o modelo de confiança do cluster do GKE. Para saber mais sobre as funções comuns e exemplos de tarefas que referimos no Google Cloud conteúdo, consulte Funções e tarefas comuns de utilizadores do GKE.
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 Konnectivity. Os pedidos que o plano de controlo envia são autenticados e protegidos pelo TLS. Quando um nó envia um pedido para o 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 são autenticadas e encriptadas. Google Cloud Para ver 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 diferentes nós 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 na camada de rede, consulte o artigo Google 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 o servidor da API e os certificados de cliente 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 duração total limitada, conforme descrito na secção Duração total 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 as 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 baseiam-se na AC raiz do cluster para estabelecer confiança. No GKE, o certificado da API do plano de controlo é assinado pela CA 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 à medida 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 suas 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 do 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.