Sobre a autoridade do plano de controle do GKE

Este documento descreve as opções que o Google Kubernetes Engine (GKE) oferece para melhorar a visibilidade e o controle sobre a segurança do plano de controle gerenciado. Essas opções são chamadas coletivamente de GKE control plane authority. Este documento é destinado a líderes de segurança da informação, administradores de compliance e analistas que querem atender a necessidades rigorosas de privacidade e segurança para o tratamento de dados sensíveis.

Sobre os recursos do GKE control plane authority

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

O GKE control plane authority é um conjunto opcional de recursos de visibilidade e controle que permitem 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 os seguintes:

  • Você opera em um setor altamente regulamentado, como finanças, saúde ou governo, com requisitos de compliance específicos.
  • Você trata dados sensíveis que têm requisitos rigorosos de segurança e criptografia.
  • Você quer mais visibilidade sobre o GKE para melhorar a 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 geração de registros.
  • 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 regulatórios específicos.
  • Você quer um nível aprimorado de transparência e visibilidade nos ambientes do GKE, especialmente em relação às ações que Google Cloud são realizadas no plano de controle.

Benefícios do GKE control plane authority

Os recursos do GKE control plane authority são ideais em ambientes altamente regulamentados que têm políticas de segurança ou requisitos de auditoria rigorosos. O uso desses recursos oferece benefícios como os seguintes:

  • Visibilidade e controle aprimorados: use mais recursos de visibilidade, controle e criptografia para o plano de controle do GKE.
  • Compliance simplificado: atenda aos requisitos regulatórios e do setor com registros de auditoria granulares e políticas de segurança personalizáveis.
  • Maior confiança e transparência: tenha insights sobre as ações que Google Cloud são realizadas 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.
  • AC e gerenciamento de chaves padronizados: gerencie as ACs do cluster do GKE usando o Certificate Authority Service, permitindo delegar o gerenciamento de certificados a equipes específicas e aplicar políticas de AC de forma abrangente. Além disso, gerencie as chaves de criptografia de disco do plano de controle usando o Cloud KMS para delegação de gerenciamento semelhante.

Disponibilidade do GKE control plane authority

O GKE control plane authority está disponível em qualquer Google Cloud região. No entanto, para criptografar os discos de inicialização e os discos etcd do plano de controle com suas próprias chaves, é necessário criar o cluster em uma das seguintes regiões:

  • asia-east1
  • asia-northeast1
  • asia-southeast1
  • europe-west1
  • europe-west4
  • us-central1
  • us-central2
  • us-east1
  • us-east4
  • us-east5
  • us-south1
  • us-west1
  • us-west3
  • us-west4

Como o GKE control plane authority funciona

Os recursos que podem ser usados com o plano de controle são categorizados com base no tipo de controle desejado, conforme mostrado abaixo. É possível usar um ou mais desses 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 da Transparência no acesso para verificar o acesso ao plano de controle do GKE usando várias fontes. Use registros de emissão de identidade no Cloud KMS e no CA Service para saber quando as identidades são criadas usando chaves e ACs que você gerencia. Use registros detalhados de uso da API Kubernetes para acompanhar o que essas identidades fazem no cluster.

Gerenciamento de chaves e credenciais

Por padrão, Google Cloud gerencia as chaves e ACs nos seus clusters do GKE. Opcionalmente, é possível usar Cloud KMS e CA Service para configurar suas próprias chaves e ACs, que serão usadas ao criar um novo cluster.

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

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

ACs 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 CA Service 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 do portador da conta de serviço do Kubernetes.

Crie os seguintes recursos para o GKE usar ao emitir identidades:

  1. Chaves de assinatura da conta de serviço: assinam os tokens do portador da ServiceAccount do Kubernetes para contas de serviço no cluster. Esses tokens do portador são tokens da Web JSON (JWTs) que facilitam a comunicação do pod com o servidor da API Kubernetes.
  2. Chaves de verificação da conta de serviço: verificam 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 de cluster: emite certificados assinados para fins como solicitações de assinatura de certificado (CSRs) e comunicação kubelet.
  4. AC de pares etcd: emite certificados assinados para comunicação entre instâncias 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 ativar 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, que pode ser usado para acompanhar as identidades emitidas durante o ciclo de vida delas.

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 etcd

Por padrão, o GKE criptografa o disco de inicialização de uma VM do plano de controle. Se o plano de controle executar instâncias de banco de dados etcd, o GKE também criptografará o seguinte:

  • O disco que armazena dados etcd.
  • O Google Cloud backup operacional interno do etcd.

Essa criptografia padrão usa chaves de criptografia que Google Cloud gerencia. Para mais detalhes sobre essa criptografia padrão, consulte Criptografia padrão em repouso.

É possível 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 inicializar.
  • Disco etcd: o disco do Compute Engine anexado a cada VM do plano de controle e que armazena dados para instâncias etcd no cluster.

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

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

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

Essa criptografia opcional adicional é ideal se você precisar atender a requisitos regulatórios ou de compliance específicos relacionados ao controle dos meios de criptografia no plano de controle do cluster. É possível usar suas próprias chaves separadamente 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 o GKE control plane authority para criptografar os discos de inicialização do plano de controle, as VMs do plano de controle do GKE usam automaticamente o modo confidencial para o Hyperdisk Balanced nos discos de inicialização. Essa configuração não altera os discos de inicialização padrão dos nós de trabalho.

Rotação de credenciais gerenciadas pelo cliente

Com o GKE control plane authority, é possível configurar clusters para usar ACs e chaves gerenciadas pelo cliente em vez dos recursos gerenciados pelo Google que o GKE usa por padrão. Uma rotação de credenciais é uma operação realizada para atualizar um ou mais desses recursos em um cluster. É possível realizar uma rotação de credenciais por motivos como evitar o vencimento da AC ou obedecer aos requisitos de gerenciamento de credenciais da sua organização.

Para realizar uma rotação de credenciais em um cluster que usa o GKE control plane authority, crie novas ACs, chaves de assinatura e chaves de criptografia. Em seguida, atualize o cluster para usar esses novos recursos.

Para mais informações, consulte as seguintes páginas:

Registros de acesso e de emissão de identidade

É possível visualizar registros no Logging para todos os eventos relacionados a 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 de Transparência no acesso.
  • Emissão e verificação de identidade: registros relacionados a identidades que foram emitidas usando ACs e chaves gerenciadas no CA Service 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 no acesso: registros relacionados a conexões feitas com o plano de controle e ações realizadas no plano de controle por Google Cloud funcionários. Quando a aprovação de acesso aumentada está ativada, você tem mais granularidade para o controle de acesso, incluindo detalhes do comando SSH nos registros de Transparência no acesso e para solicitações de aprovação de acesso. Para mais informações sobre qualificação e inscrição, entre em contato com a equipe de conta Google Cloud .

Esses registros podem ajudar você a fazer o seguinte:

  • Manter 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, é possível criar seu próprio monitoramento para identificar e investigar qualquer atividade suspeita no plano de controle.
  • Verificar se apenas entidades autorizadas acessam e interagem com o cluster do GKE, o que melhora a postura de segurança.
  • Verificar quando as identidades são criadas usando chaves e ACs gerenciadas usando registros de emissão de identidade no Cloud KMS e no CA Service. Use registros detalhados de uso 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 o GKE control plane authority para usar os seguintes recursos:

A seguir