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 (em inglês), 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 ver uma descrição detalhada dos recursos de segurança integrados ao Container-Optimized OS, consulte a visão geral de segurança desse sistema.

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 site 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, 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útua. Ou seja, cada servidor precisa provar a própria identidade para o outro. Em um cluster regional, a comunicação entre os servidores do etcd para estabelecer um quórum é criptografada por TLS mútua (em inglês).

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 (página em inglês). Um serviço interno do Google gerencia chaves raiz para essa 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 nós e o servidor da API Kubernetes é protegida por 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.

No GKE, as novas correções no kernel, no SO e no Kubernetes são aplicadas rapidamente às VMs do plano de controle. Quando as correções estão relacionadas a vulnerabilidades conhecidas, as 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 em busca de 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 no da vulnerabilidade dnsmasq (em inglês), de outubro de 2017, o GKE corrigiu todos os clusters em execução antes que ela 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 Audit Logging é ativado por padrão para clusters criados desde a 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 mestres autorizadas e clusters particulares, que permitem atribuir um endereço IP particular ao servidor da API Kubernetes e desativar o acesso no endereço IP público.

Para processar a autenticação de cluster no Google Kubernetes Engine, use o Cloud IAM como o provedor de identidade. Para reforçar a segurança da autenticação, a autenticação básica e a emissão de certificados do cliente estão desativadas por padrão nos clusters criados com o GKE 1.12 e posterior.

É 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