Segurança do plano de controlo

Esta página descreve como o Google Kubernetes Engine (GKE) protege os componentes do plano de controlo do cluster. Saiba mais sobre as funcionalidades de segurança incorporadas no GKE, que incluem um SO com segurança reforçada, uma arquitetura robusta e isolamento, acesso seguro ao plano de controlo, segurança para a base de dados de estado do cluster baseada em etcd ou Spanner, autoridade de certificação e confiança do cluster, bem como gestão de patches e vulnerabilidades.

Esta página destina-se a especialistas em segurança que querem compreender como a Google gere os componentes do plano de controlo do GKE e as medidas de segurança implementadas para avaliar eficazmente o risco e garantir a segurança das suas implementações do GKE.

Ao abrigo do modelo de responsabilidade partilhada, a Google gere os componentes do plano de controlo do GKE por si. O plano de controlo inclui o servidor de API Kubernetes, o armazenamento de objetos da API Kubernetes e outros controladores. A Google é responsável por proteger o plano de controlo, embora possa configurar determinadas opções com base nos seus requisitos. É responsável por proteger os seus nós, contentores e pods.

Sistema operativo reforçado

Os componentes do plano de controlo do GKE são executados no SO otimizado para contentores, que é um sistema operativo reforçado em termos de segurança concebido pela Google. Para uma descrição detalhada das funcionalidades de segurança incorporadas no SO otimizado para contentores, consulte a vista geral da segurança do SO otimizado para contentores.

Arquitetura e isolamento

Num cluster do GKE, os componentes do plano de controlo são executados em instâncias do Compute Engine pertencentes à Google, num projeto gerido pela Google. Cada instância executa estes componentes apenas para um cluster.

Para ver detalhes sobre como os componentes do cluster se autenticam entre si, consulte o artigo Fidedignidade do cluster.

Controle o acesso do plano de controlo ao seu projeto

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

O agente do serviço do Kubernetes Engine tem o seguinte endereço de email:

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

Neste endereço de email, PROJECT_NUMBER é o seu número do projeto.

Acesso administrativo ao cluster

As sessões SSH dos engenheiros de fiabilidade de sites da Google são registadas em auditoria através da infraestrutura de auditoria interna da Google, que está disponível para análise forense e resposta de segurança. Para mais informações, consulte Acesso administrativo no documento técnico sobre segurança da Google.

Segurança da base de dados do estado do cluster

No Trusted Cloud by S3NS, o conteúdo do cliente é encriptado por predefinição na camada do sistema de ficheiros. Esta encriptação inclui a infraestrutura que aloja a base de dados baseada em etcd ou Spanner que armazena o estado dos objetos da API Kubernetes no seu cluster. Para mais informações sobre a base de dados do estado do cluster, consulte o artigo Arquitetura do cluster do GKE.

A base de dados de estado do cluster armazena a configuração de cada objeto da API Kubernetes no seu cluster como pares de chave-valor. O GKE usa portas TCP específicas em VMs do plano de controlo para os seguintes tipos de comunicação com a base de dados de estado do cluster:

  • Clientes da API etcd: o GKE disponibiliza a API etcd em todas as VMs do plano de controlo. Os clientes da API etcd no plano de controlo, como o servidor da API Kubernetes, usam uma das seguintes portas:

    • Porta 2379: esta porta é usada quando o GKE armazena o estado do cluster em instâncias da base de dados etcd que são executadas em cada VM do plano de controlo.
    • Porta 3379: esta porta é usada quando o GKE armazena o estado do cluster numa base de dados do Spanner separada do plano de controlo.

    A porta que os clientes da API etcd usam está associada à interface de rede de loopback local e só é acessível a partir da VM do plano de controlo que está a executar o servidor da API Kubernetes.

  • Instâncias da base de dados etcd: se as VMs do plano de controlo executarem instâncias da base de dados etcd, os servidores da API etcd em cada VM usam a porta 2380 para comunicar entre si. O tráfego na porta 2380 entre instâncias da base de dados etcd em várias VMs do plano de controlo (como em clusters regionais) é encriptado por TLS mútuo. Com o TLS mútuo, cada servidor tem de provar a sua identidade ao outro.

    A porta 2380 não é usada em clusters que armazenam o estado do cluster numa base de dados do Spanner porque a base de dados não é executada nas VMs do plano de controlo.

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

Cada cluster tem a sua própria autoridade de certificação (AC) raiz. Um serviço interno da Google gere as chaves de raiz desta AC. As chaves de raiz desta AC são distribuídas aos metadados das VMs que executam o servidor da API Kubernetes. A comunicação entre os nós e o servidor da API Kubernetes é protegida por TLS. Cada cluster também tem a sua própria AC para a API etcd e, se o cluster executar instâncias da base de dados etcd, para o tráfego entre instâncias etcd. Para mais informações, consulte o artigo Confiança do cluster.

Gestão de vulnerabilidades e patches

O GKE cumpre as normas da Google para testar, qualificar e implementar gradualmente alterações ao plano de controlo. Isto minimiza o risco de um componente do plano de controlo ficar indisponível. O GKE cumpre um contrato de nível de serviço que define muitos aspetos da disponibilidade.

Os componentes do plano de controlo do GKE são geridos por uma equipa de engenheiros de fiabilidade do site da Google e são mantidos atualizados com os patches de segurança mais recentes. Isto inclui patches para o sistema operativo anfitrião, os componentes do Kubernetes e os contentores em execução nas VMs do plano de controlo.

O GKE aplica novas correções ao nível do SO, do kernel e do Kubernetes rapidamente às VMs do plano de controlo. Quando contêm correções para vulnerabilidades conhecidas, estão disponíveis informações adicionais nos boletins de segurança do GKE. O GKE analisa todas as vulnerabilidades do sistema Kubernetes e dos contentores específicos do GKE através da Análise de artefactos e mantém os contentores corrigidos, o que beneficia todo o ecossistema do Kubernetes.

Os engenheiros da Google participam na deteção, correção e divulgação de erros de segurança do Kubernetes. A Google também paga a investigadores de segurança externos, através do Vulnerability Reward Program ao nível da Google, para procurarem erros de segurança. Em alguns casos, como a vulnerabilidade dnsmasq em outubro de 2017, o GKE conseguiu aplicar patches a todos os clusters em execução antes de a vulnerabilidade se tornar pública.

O que pode ver

As funcionalidades de segurança abordadas nas secções anteriores são geridas pela Google. Esta secção e a secção O que pode configurar descrevem as funcionalidades de segurança que pode monitorizar e configurar.

  • Registos de auditoria: o registo de auditoria está ativado por predefinição. Isto fornece um registo detalhado, disponível no Google Cloud Observability, das chamadas feitas ao servidor da API Kubernetes. Pode ver as entradas do registo no Explorador de registos naTrusted Cloud consola. Também pode usar o BigQuery para ver e analisar estes registos.

  • Integridade da imagem de VM do plano de controlo: o GKE adiciona registos detalhados para eventos de criação e arranque de VMs de nós ao Cloud Logging. Além disso, publicamos VSAs SLSA no GitHub que correspondem a imagens de máquinas do plano de controlo e do nó de worker. Pode verificar se as suas VMs usam imagens do SO com VSAs correspondentes e verificar a integridade do arranque de cada VM do plano de controlo.

    Para realizar a validação da integridade da VM, consulte o artigo Valide a integridade da VM do plano de controlo do GKE.

O que pode configurar

Embora o GKE faça a gestão da maioria do plano de controlo por si, pode controlar o seguinte:

  • Acesso ao plano de controlo: o plano de controlo tem dois tipos de pontos finais para acesso ao cluster:

    • Ponto final baseado em DNS
    • Pontos finais baseados em IP

    Por predefinição, o servidor da API Kubernetes usa um endereço IP externo. Pode proteger o servidor da API Kubernetes ativando um ponto final baseado em DNS para aceder ao plano de controlo. Pode controlar quem pode aceder ao ponto final de DNS com os VPC Service Controls, que lhe permitem definir um parâmetro de segurança para todas as APIs Google no seu projeto. Se usar pontos finais baseados em IP para acesso ao plano de controlo, recomendamos que use redes autorizadas e desative o acesso no ponto final externo do plano de controlo. Para mais informações sobre o isolamento de rede, consulte o artigo Acerca da personalização do isolamento de rede.

  • Autenticação: pode processar a autenticação de clusters no GKE através da IAM como fornecedor de identidade. Para melhorar a segurança da autenticação, a autenticação básica e a emissão de certificados de cliente estão desativadas por predefinição.

  • Rotação de credenciais: rode a autoridade de certificação (AC) do cluster e os certificados TLS regularmente através de uma rotação de credenciais. O GKE também roda o endereço IP do seu servidor da API Kubernetes durante este processo. Para mais informações, consulte o artigo sobre a rotação de credenciais.

Além disso, se a sua organização tiver requisitos de conformidade ou políticas rigorosos relacionados com o plano de controlo, a autoridade do plano de controlo do GKE é um conjunto de funcionalidades que lhe oferece maior visibilidade e controlo sobre aspetos específicos do plano de controlo, incluindo o seguinte:

  • Execute as suas próprias ACs e chaves para a emissão de identidades através do Cloud KMS e do CA Service.
  • Encripte os discos de arranque do etcd e do plano de controlo com as suas próprias chaves no Cloud KMS.

Para ver detalhes sobre os motivos pelos quais usaria estas funcionalidades e todas as capacidades disponíveis, consulte o artigo Acerca da autoridade do plano de controlo do GKE.

O que se segue?