Segurança do plano de controle

Neste documento, descrevemos como os componentes do plano de controle de cluster são protegidos no Google Kubernetes Engine.

No modelo de responsabilidade compartilhada, o Google gerencia os componentes do plano de controle do GKE para você. O plano de controle inclui o servidor da API Kubernetes, o etcd e vários controladores. O Google é responsável por proteger o plano de controle, mas é possível configurar determinadas opções com base nos seus requisitos. Você é responsável por proteger seus nós, contêineres e pods.

Sistema operacional com aumento da proteção

Os componentes do plano de controle do GKE são executados no Container-Optimized OS, que é um sistema operacional com segurança reforçada desenvolvido pelo Google. Para conseguir uma descrição detalhada dos recursos de segurança integrados ao Container Optimized OS, consulte a visão geral de segurança do Container-Optimized OS.

Arquitetura e isolamento

Em um cluster do GKE, os componentes do plano de controle são executados em instâncias do Compute Engine de propriedade do Google, em um projeto gerenciado pelo Google. Cada instância executa esses componentes para apenas um cliente.

A autenticação no servidor da API Kubernetes e no etcd é feita da mesma maneira que é feita para outros serviços do Google Cloud. A segurança de transporte da camada de aplicativo (ALTS, na sigla em inglês) protege essas comunicações.

Acesso administrativo ao cluster

As sessões SSH dos engenheiros de confiabilidade do Google Sites são registradas em auditoria por meio da infraestrutura de auditoria interna do Google, que está disponível para análise forense e de segurança. Para saber mais informações, consulte Acesso administrativo no whitepaper de segurança do Google.

Segurança do etcd

No Google Cloud Platform, o conteúdo do cliente é criptografado na camada do sistema de arquivos por padrão. Portanto, os discos que hospedam o armazenamento do etcd para os clusters do GKE são criptografados na camada do sistema de arquivos. Para mais informações, consulte Criptografia em repouso.

O etcd escuta em duas portas TCP. A porta 2379 é para clientes do etcd, como o servidor da API Kubernetes. A porta 2379 está vinculada à interface de rede de loopback local, portanto, ela só pode ser acessada pela VM que está executando o servidor da API Kubernetes. A porta 2380 é para comunicação de servidor para servidor. O tráfego na porta 2380 é criptografado por TLS mútuo. Ou seja, cada servidor precisa provar sua identidade para o outro. Em um cluster regional, a comunicação entre os servidores do etcd para estabelecer um quorum é criptografada por TLS mútuo.

Autoridade de certificação e confiança de cluster

Cada cluster tem a própria autoridade de certificação (CA, na sigla em inglês) raiz. Um serviço interno do Google gerencia as chaves raiz dessa CA. Cada cluster também tem a própria CA para o etcd. As chaves raiz da CA do etcd são distribuídas para os metadados das VMs que executam o servidor da API Kubernetes. A comunicação entre os nós e o servidor da API Kubernetes é protegida pelo TLS. Para mais informações, consulte Confiança de cluster.

Vulnerabilidade e gerenciamento de patches

O GKE segue os padrões do Google para testes, qualificação e implantação gradual de alterações no plano de controle. Isso minimiza o risco de um componente do plano de controle ficar indisponível. O GKE adere a um acordo de nível de serviço que define muitos aspectos da disponibilidade.

Os componentes do plano de controle do GKE são gerenciados por uma equipe de engenheiros de confiabilidade de sites do Google e atualizados com os patches de segurança mais recentes. Isso inclui patches para o sistema operacional do host, componentes do Kubernetes e contêineres em execução nas VMs do plano de controle.

O GKE aplica novas correções no nível do kernel, do SO e do Kubernetes prontamente para controlar as VMs do plano. Quando estes contêm correções para vulnerabilidades conhecidas, mais informações são disponibilizadas nos boletins de segurança do GKE. O GKE analisa todo o sistema Kubernetes e contêineres específicos do GKE quanto a vulnerabilidades usando a verificação de vulnerabilidades do Container Registry e mantém os contêineres corrigidos, beneficiando todo o ecossistema do Kubernetes.

Os engenheiros do Google participam da descoberta, correção e divulgação de bugs de segurança do Kubernetes. E o Google paga a pesquisadores de segurança externos, por meio do programa de recompensa de vulnerabilidade do Google, para procurar por bugs de segurança. Em alguns casos, como a vulnerabilidade dnsmasq em outubro de 2017, o GKE conseguiu corrigir todos os clusters em execução antes que a vulnerabilidade se tornasse pública.

O que pode ser visto

Os recursos de segurança discutidos anteriormente neste tópico são gerenciados pelo Google. Esta seção e a seção a seguir discutem os recursos de segurança que podem ser monitorados e configurados.

O log de auditoria é habilitado por padrão para clusters criados desde o lançamento da versão 1.8.3. Isso fornece um registro detalhado, disponível no Stackdriver, das chamadas feitas ao servidor da API Kubernetes. É possível visualizar as entradas de registro na página Registros no Console do GCP. Também é possível usar o BigQuery para visualizar e analisar esses registros.

O que pode ser configurado

Por padrão, o servidor da API Kubernetes usa um endereço IP público. É possível proteger o servidor da API Kubernetes usando redes principais autorizadas e clusters particulares, que permitem atribuir um endereço IP particular ao servidor e desativar o acesso no endereço IP público.

É possível manipular a autenticação de cluster no GKE usando o Cloud IAM como o provedor de identidade. É preciso desativar a Autenticação Básica, definindo um nome de usuário e senha vazios para a configuração do MasterAuth. Na mesma configuração, também é possível desativar o certificado de cliente. Assim, você terá uma chave a menos para pensar ao bloquear o acesso ao cluster.

É possível melhorar a segurança do seu plano de controle fazendo a rotação de credenciais regularmente. Quando a rotação de credenciais é iniciada, os certificados TLS e a autoridade de certificação de cluster são girados automaticamente. O GKE também gira o endereço IP do seu servidor da API Kubernetes. Para mais informações, consulte Controle de acesso baseado em papéis e Rotação de credenciais.

A seguir

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

Enviar comentários sobre…

Documentação do Kubernetes Engine