Segurança do plano de controle

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ê 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 em vigor para avaliar os riscos de maneira eficaz 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 de API Kubernetes, o repositório 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.

Acesso do plano de controle ao seu 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 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 do 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 executa o servidor de 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 sua 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 certificadora raiz (AC). 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 de API Kubernetes. A comunicação entre os nós e o servidor de 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 do 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. Esta seção e a O que você pode configurar descrevem recursos de segurança que podem ser monitorados e configurados.

  • Registros de auditoria: a geração de registros de auditoria é ativada por padrão. Isso fornece um registro detalhado, disponível no Google Cloud Observability, das chamadas feitas ao servidor de API Kubernetes. É possível ver as entradas de registro na Análise 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 eventos de criação e inicialização de VMs de nó ao Cloud Logging. Além disso, publicamos VSAs do SLSA no GitHub que correspondem às imagens de máquina do plano de controle e do nó de trabalho. É possível verificar se as VMs usam imagens do SO que têm VSAs correspondentes e verificar a integridade de 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 de API Kubernetes usa um endereço IP externo. É possível proteger o servidor de API do Kubernetes ativando um endpoint baseado em DNS para acesso ao plano de controle. Você pode 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 acessar o 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 Sobre a personalização do isolamento de rede.

  • Autenticação: é possível processar a autenticação de cluster no GKE usando o IAM como provedor de identidade. Para aumentar a segurança da autenticação, a autenticação básica e a emissão de certificados do cliente são desativadas por padrão.

  • Rotação de credenciais: faça a rotação da autoridade certificadora (CA) do cluster e dos certificados TLS regularmente realizando uma rotação de credenciais. O GKE também faz a rotação do endereço IP do servidor de API Kubernetes durante esse processo. Para mais informações, consulte rotação de credenciais.

Além disso, se a organização tiver requisitos da política ou de compliance rígidos relacionados ao plano de controle, a GKE control plane authority será um conjunto de recursos que oferecem maior visibilidade e controle sobre aspectos específicos do plano de controle, incluindo o seguinte:

  • Execute suas próprias CAs e chaves para emissão de identidade usando o Cloud KMS e o CA Service.
  • Criptografe o etcd e os discos de inicialização do plano de controle usando suas próprias chaves no Cloud KMS.

Para saber por que usar esses recursos e conhecer todas as funcionalidades disponíveis, consulte Sobre a autoridade do plano de controle do GKE.

A seguir