Neste documento, descrevemos como o Google Kubernetes Engine (GKE) ajuda a proteger os componentes do plano de controle do cluster. Este documento pressupõe que você já conheça o seguinte:
Este documento é destinado a especialistas em segurança que querem entender como o Google gerencia os componentes do plano de controle do GKE e as medidas de segurança implementadas para avaliar o risco e garantir a segurança das implantações do GKE.
O GKE inclui recursos de segurança integrados, como um SO com segurança reforçada, arquitetura e isolamento robustos, acesso seguro ao plano de controle, segurança para o banco de dados de estado do cluster baseado em etcd ou Spanner, autoridade de certificação e confiança do cluster, além de gerenciamento de vulnerabilidades e patches.
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 de objetos da API Kubernetes 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 banco de dados de estado do cluster
No Google Cloud, o conteúdo do cliente é criptografado na camada do sistema de arquivos por padrão. Essa criptografia inclui a infraestrutura que hospeda o banco de dados baseado em etcd ou Spanner que armazena o estado dos objetos da API Kubernetes no seu cluster. Para mais informações sobre o banco de dados de estado do cluster, consulte Arquitetura de cluster do GKE.
O banco de dados de estado do cluster armazena a configuração de cada objeto da API Kubernetes no cluster como pares de chave-valor. O GKE usa portas TCP específicas em VMs do plano de controle para os seguintes tipos de comunicação com o banco de dados de estado do cluster:
Clientes da API etcd: o GKE veicula a API etcd em todas as VMs do plano de controle. Os clientes da API etcd no plano de controle, como o servidor da API Kubernetes, usam uma das seguintes portas:
- Porta 2379: usada quando o GKE armazena o estado do cluster em instâncias de banco de dados etcd executadas em cada VM do plano de controle.
- Porta 3379: usada quando o GKE armazena o estado do cluster em um banco de dados do Spanner separado do plano de controle.
A porta usada pelos clientes da API etcd está vinculada à interface de rede de loopback local e só pode ser acessada pela VM do plano de controle que está executando o servidor da API Kubernetes.
Instâncias de banco de dados etcd: se as VMs do plano de controle executarem instâncias de banco de dados etcd, os servidores de API etcd em cada VM usarão a porta 2380 para se comunicar entre si. O tráfego na porta 2380 entre instâncias de banco de dados etcd em várias VMs do plano de controle (como em clusters regionais) é criptografado por TLS mútuo. Com o TLS mútuo, cada servidor precisa provar a própria identidade para o outro.
A porta 2380 não é usada em clusters que armazenam o estado do cluster em um banco de dados do Spanner porque o banco de dados não é executado nas VMs do plano de controle.
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. As chaves raiz dessa CA 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. Cada cluster também tem a própria CA para a API etcd e, se o cluster executar instâncias de banco de dados etcd, para o tráfego entre instâncias etcd. 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 nas seções anteriores são gerenciados pelo Google. Nesta seção e na seção O que pode ser configurado, descrevemos os recursos de segurança que podem ser monitorados e configurados.
- Registros de auditoria: o registro de auditoria é ativado por padrão. 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 doGoogle Cloud . Também é possível usar o BigQuery para visualizar e analisar esses registros.
Integridade da imagem da VM do plano de controle: o GKE adiciona registros detalhados para a criação de VMs de nós e eventos de inicialização ao Cloud Logging. Além disso, publicamos VSAs da SLSA no GitHub que correspondem a imagens de máquina do plano de controle e do nó de trabalho. É possível verificar se as VMs usam imagens do SO com VSAs correspondentes e verificar a integridade da inicialização de cada VM do plano de controle.
Para realizar a verificação de integridade da VM, consulte Verificar a integridade da VM do plano de controle do GKE.
O que pode ser configurado
Embora o GKE gerencie a maior parte do plano de controle para você, é possível controlar o seguinte:
Acesso ao plano de controle: o plano de controle tem dois tipos de endpoints para acesso ao cluster:
- Endpoint baseado em DNS
- Endpoints baseados em IP
Por padrão, o servidor da API Kubernetes usa um endereço IP externo. É possível proteger o servidor da API Kubernetes ativando um endpoint baseado em DNS para acesso ao plano de controle. É possível controlar quem pode acessar o endpoint DNS com o VPC Service Controls, que permite definir um parâmetro de segurança para todas as APIs do Google no seu projeto. Se você estiver usando endpoints baseados em IP para acesso ao plano de controle, recomendamos usar redes autorizadas e desativar o acesso no endpoint externo do plano de controle. Para mais informações sobre isolamento de rede, consulte Como personalizar o isolamento de rede.
Autenticação: é possível processar a autenticação de cluster no GKE usando 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.
Rotação de credenciais: faça a rotação da autoridade de certificação (CA) do cluster e dos certificados TLS regularmente realizando uma rotação de credenciais. O GKE também rotaciona o endereço IP do servidor da API Kubernetes durante esse processo. Para mais informações, consulte rotação de credenciais.
Além disso, se a organização tiver requisitos rígidos de compliance ou política relacionados ao plano de controle, a autoridade do plano de controle do GKE será um conjunto de recursos que oferece mais visibilidade e controle sobre aspectos específicos do plano de controle, incluindo:
- Execute suas próprias CAs e chaves para emissão de identidade usando o Cloud KMS e o Serviço de CA.
- Criptografe os discos de inicialização do etcd e do plano de controle usando suas próprias chaves no Cloud KMS.
Para detalhes sobre por que usar esses recursos e todas as funcionalidades disponíveis, consulte Sobre a autoridade do plano de controle do GKE.
A seguir
- Visão geral da segurança
- Visão geral da segurança do Container-Optimized OS
- Como aumentar a segurança do seu cluster