Sobre a autoridade do plano de controle do GKE

Esta página descreve as opções oferecidas pelo Google Kubernetes Engine (GKE) para melhorar sua visibilidade e controle sobre a segurança do plano de controle gerenciado. Essas opções são chamadas coletivamente de autoridade do plano de controle do GKE. Esta página é destinada a líderes de segurança da informação, administradores de compliance e analistas que querem atender a necessidades rígidas de privacidade e segurança para o processamento de dados sensíveis.

Sobre os recursos de autoridade do plano de controle do GKE

No GKE,o Google Cloud gerencia totalmente a configuração de segurança do plano de controle, incluindo a criptografia do armazenamento em repouso e a configuração das chaves e autoridades de certificação (ACs, na sigla em inglês) que assinam e verificam as credenciais nos clusters. Os nós do plano de controle para clusters do GKE existem em projetos que o Google Cloud gerencia. Para saber mais sobre o que o Google Cloud faz, consulte Responsabilidade compartilhada do GKE.

A autoridade do plano de controle do GKE é um conjunto opcional de recursos de visibilidade e controle que permite verificar e gerenciar aspectos específicos desses nós de plano de controle totalmente gerenciados. Esses recursos são ideais se você tiver requisitos como estes:

  • Você opera em um setor altamente regulamentado, como finanças, saúde ou governo, com requisitos de compliance específicos.
  • Você lida com dados sensíveis que têm requisitos rígidos de segurança e criptografia.
  • Você quer melhorar a visibilidade do GKE para aumentar sua confiança ao executar cargas de trabalho críticas
  • Você precisa atender a requisitos específicos de compliance ou auditoria relacionados à criptografia de dados, integridade de software ou registro.
  • Você tem cargas de trabalho altamente sensíveis que processam dados críticos e quer visibilidade sobre a criptografia e o acesso a esses dados
  • Você quer aplicar políticas de segurança personalizadas que atendam a requisitos organizacionais ou regulamentares específicos.
  • Você quer um nível aprimorado de transparência e visibilidade nos seus ambientes do GKE, especialmente em relação a ações que oGoogle Cloud executa no plano de controle.

Benefícios da autoridade do plano de controle do GKE

Os recursos de autoridade do plano de controle do GKE são ideais em ambientes altamente regulamentados com políticas de segurança ou requisitos de auditoria rigorosos. O uso desses recursos oferece benefícios como:

  • Maior visibilidade e controle: use outros recursos de visibilidade, controle e criptografia para seu plano de controle do GKE.
  • Compliance simplificado: atenda aos requisitos regulamentares e do setor com registros de auditoria granulares e políticas de segurança personalizáveis.
  • Mais confiança e transparência: receba insights sobre as ações que o Google Cloud usa no plano de controle ao resolver casos de suporte ao cliente.
  • Mitigação de riscos: detecte e responda proativamente a possíveis ameaças ao plano de controle gerenciado com registros abrangentes.
  • Gerenciamento de chaves e AC padronizados: gerencie as ACs do cluster do GKE usando o Certificate Authority Service, permitindo que você delegue o gerenciamento de certificados a equipes específicas e aplique de forma abrangente as políticas da AC. Além disso, gerencie as chaves de criptografia de disco do plano de controle usando o Cloud KMS para delegação de gerenciamento semelhante.

Como funciona a autoridade do plano de controle do GKE

Os recursos que podem ser usados com o plano de controle são categorizados com base no tipo de controle desejado, conforme abaixo. É possível usar um ou mais esses recursos com base nos seus requisitos específicos.

  • Gerenciamento de chaves e credenciais: controle as chaves que o GKE usa para criptografar dados em repouso no plano de controle e para emitir e verificar identidades no cluster.
  • Registros de acesso e de emissão de identidade: use registros da rede, da VM e do Transparência no acesso para verificar o acesso ao plano de controle do GKE usando várias fontes. Use os registros de emissão de identidade no Cloud KMS e no serviço de AC para saber quando as identidades são criadas usando chaves e ACs que você gerencia. Use registros de uso detalhados da API do Kubernetes para acompanhar o que essas identidades fazem no cluster.

Gerenciamento de chaves e credenciais

Por padrão,o Google Cloud gerencia as chaves e as ACs nos seus clusters do GKE. Você pode usar o Cloud KMS e o CA Service para configurar suas próprias chaves e ACs, que serão usadas na criação de um novo cluster.

O GKE usa essas chaves e ACs em vez do Google Cloud como padrão para emitir e verificar identidades no cluster e criptografar dados nas VMs do plano de controle. Manter o controle da emissão de identidade e das chaves de criptografia de dados pode ajudar você a fazer o seguinte:

  • Obedecer às regulamentações de privacidade e soberania de dados que exigem o controle exclusivo de chaves
  • Controle a criptografia de dados sensíveis importantes no Kubernetes gerenciando suas próprias chaves de criptografia
  • Personalize sua estratégia de criptografia de dados com base nas políticas e nos requisitos da sua organização, como requisitos para usar chaves com suporte de hardware.

Autoridades certificadoras autogerenciadas e chaves de conta de serviço

É possível configurar o plano de controle do GKE para usar chaves do Cloud KMS e ACs do serviço de AC que você gerencia. O GKE usa esses recursos para emitir e verificar identidades no cluster. Por exemplo, o GKE usa ACs e chaves para emitir certificados de cliente do Kubernetes e tokens de portador da conta de serviço do Kubernetes.

Crie os seguintes recursos para que o GKE os use ao emitir identidades:

  1. Chaves de assinatura da conta de serviço: assine os tokens de portador da conta de serviço do Kubernetes para contas de serviço no cluster. Esses tokens de portador são tokens da Web JSON (JWTs) que facilitam a comunicação do pod com o servidor da API do Kubernetes.
  2. Chaves de verificação da conta de serviço: verifique os JWTs da conta de serviço do Kubernetes. Essa chave normalmente é a mesma que a chave de assinatura, mas é configurada separadamente para que você possa alternar as chaves com mais segurança.
  3. AC do cluster: emite certificados assinados para finalidades como solicitações de assinatura de certificado (CSRs) e comunicação do kubelet.
  4. CA do peer do etcd: emite certificados assinados para a comunicação entre instâncias do etcd no cluster.
  5. AC da API etcd: emite certificados assinados para comunicação com o servidor da API etcd.
  6. AC de agregação: emite certificados assinados para permitir a comunicação entre o servidor da API Kubernetes e os servidores de extensão.

Quando o GKE emite identidades no cluster, os registros de auditoria correspondentes aparecem no Cloud Logging. Eles podem ser usados para rastrear as identidades emitidas durante a vida útil.

Para saber mais, consulte Executar suas próprias autoridades certificadoras e chaves de assinatura no GKE.

Disco de inicialização do plano de controle e criptografia do etcd

Por padrão, o GKE criptografa o disco de inicialização de uma VM de plano de controle, o disco que armazena dados no etcd e o Google Cloud backup operacional interno do etcd usando chaves de criptografia que o Google Cloud gerencia. Para saber mais sobre essa criptografia padrão, consulte Criptografia padrão em repouso.

Você pode opcionalmente usar suas próprias chaves de criptografia gerenciadas pelo Cloud KMS para criptografar os seguintes recursos:

  • Disco de inicialização do plano de controle: o disco do Compute Engine que cada VM do plano de controle usa para inicialização.
  • Disco etcd: o disco do Compute Engine que é anexado a cada VM do plano de controle e armazena dados para instâncias etcd no cluster.

  • Backup operacional interno do etcd: o backup interno Google Cloud do etcd que é usado para fins operacionais, como recuperação de desastres.

    Esse backup é uma medida de emergência interna do Google Cloud. Se você quiser fazer backup e restaurar seus clusters, use o Backup para GKE.

Para instruções, consulte Como criptografar o etcd e os discos de inicialização do plano de controle.

Essa criptografia opcional extra é ideal se você precisar atender a requisitos regulatórios ou de conformidade específicos relacionados ao controle dos meios de criptografia no plano de controle do cluster. É possível usar suas próprias chaves para criptografar os discos de inicialização e de armazenamento dos nós de trabalho no cluster. Para mais detalhes, consulte Usar chaves de criptografia gerenciadas pelo cliente (CMEK).

Quando você usa a autoridade do plano de controle do GKE para criptografar seus discos de inicialização do plano de controle, as VMs do plano de controle do GKE usam automaticamente o modo confidencial para o Hyperdisk equilibrado nos discos de inicialização. Essa configuração não muda os discos de inicialização padrão dos nós de trabalho.

Registros de acesso e de emissão de identidade

É possível conferir os registros no Logging para todos os eventos relacionados ao acesso e à identidade no plano de controle, incluindo os seguintes eventos:

  • Acesso direto: os registros relacionados a tentativas de acesso direto (como SSH) aos nós do plano de controle do GKE permitem verificar se os registros SSH da VM e as conexões de rede da VM correspondem aos registros SSH nos registros do Transparência no acesso.
  • Emissão e verificação de identidade: registros relacionados a identidades que foram emitidas usando ACs e chaves gerenciadas no serviço de AC e no Cloud KMS.
  • Uso de identidade no Kubernetes: registros relacionados às ações que identidades específicas realizam no servidor da API Kubernetes.
  • Transparência de acesso: registros relacionados às conexões feitas com o plano de controle e ações realizadas no plano de controle por Google Cloud .

Esses registros podem ajudar você a fazer o seguinte:

  • Mantenha trilhas de auditoria abrangentes de todos os eventos de acesso e identidade do plano de controle para compliance e segurança.
  • Além das proteções integradas do Google, você pode criar seu próprio monitoramento para identificar e investigar qualquer atividade suspeita no plano de controle.
  • Verifique se apenas entidades autorizadas acessam e interagem com seu cluster do GKE, o que melhora sua postura de segurança.
  • Confira quando as identidades são criadas usando chaves e ACs gerenciadas por você com os registros de emissão de identidade no Cloud KMS e no serviço de AC. Use registros de uso detalhados da API Kubernetes para acompanhar o que essas identidades fazem no cluster.

Os documentos a seguir mostram como visualizar e processar os vários tipos de registros do plano de controle:

Outros recursos sobre a segurança do plano de controle

Esta seção descreve outros métodos que podem ser usados para melhorar a confiança na segurança do plano de controle. Não é necessário usar a autoridade do plano de controle do GKE para usar os seguintes recursos:

  • Controle de integridade da imagem da VM: o GKE adiciona registros detalhados para a criação de VMs de nó e eventos de inicialização ao Cloud Logging. Além disso, publicamos VSAs do SLSA no GitHub que correspondem a imagens de máquina de nó de trabalho e plano de controle. É 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.

  • Medidas de segurança integradas do plano de controle: o GKE executa várias medidas de proteção no plano de controle gerenciado. Para saber mais, consulte Segurança do plano de controle.

A seguir