Segurança do plano de controle

Neste documento, descrevemos como o Google Kubernetes Engine (GKE) protege os componentes do plano de controle do cluster.

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 armazenamento etcd e outros 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.

Para detalhes sobre como os componentes do cluster se autenticam, consulte Confiança de cluster.

Controlar o acesso do plano ao projeto

O GKE usa um agente de serviço chamado de Agente de serviço do Kubernetes Engine para acionar recursos de cluster em seu nome, como nós, discos e balanceadores de carga. A conta de serviço recebe automaticamente no seu projeto o papel de Agente de serviço do Kubernetes Engine (roles/container.serviceAgent).

O agente de serviço do Kubernetes Engine tem o seguinte endereço de e-mail:

service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com

Neste endereço de e-mail, PROJECT_NUMBER é o número do projeto.

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, 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. 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 o Artifact Analysis 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. O Google também paga a pesquisadores de segurança externos pelo Programa de recompensa para descobertas de vulnerabilidades de todos os produtos do Google (em inglês), que envolve procura de 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.

A geração de registros de auditoria é ativada por padrão nos clusters criados desde a versão 1.8.3 do GKE. Isso fornece um registro detalhado, disponível na observabilidade do Google Cloud, das chamadas feitas ao servidor da API Kubernetes. É possível ver as entradas de registro no Explorador de registros no Console do Google Cloud. 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 autorizadas e clusters privados, que permitem atribuir um endereço IP privado ao Kubernetes. servidor da API e desativar o acesso no endereço IP público.

Para processar a autenticação de cluster no GKE, use o 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 versão 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 (RBAC, na sigla em inglês) e Rotação de credenciais.

A seguir