Sobre a autoridade do plano de controle do GKE

.

Nesta página, descrevemos as opções oferecidas pelo Google Kubernetes Engine (GKE) para melhorar a visibilidade e o 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 rigorosas de privacidade e segurança para lidar com 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 de armazenamento em repouso e a configuração das chaves e autoridades certificadoras (ACs) que assinam e verificam as credenciais nos seus clusters. Os nós do plano de controle para clusters do GKE existem em projetos gerenciados pelo Google Cloud . Para detalhes sobre o que 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 permitem verificar e gerenciar aspectos específicos desses nós do 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ê lida com dados sensíveis que têm requisitos rigorosos de segurança e criptografia
  • Você quer melhorar a visibilidade do GKE para aumentar a confiança ao executar cargas de trabalho críticas.
  • Você precisa atender a requisitos específicos de compliance ou auditoria relacionados a criptografia de dados, integridade de software ou registro em log.
  • Você tem cargas de trabalho altamente sensíveis que processam dados críticos e quer visibilidade da criptografia e do 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 maior de transparência e visibilidade nos seus ambientes do GKE, principalmente em relação às ações que oGoogle Cloud realiza 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 mais 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 realiza no plano de controle ao resolver casos de suporte ao cliente.
  • Redução de riscos: detecte e responda proativamente a possíveis ameaças ao plano de controle gerenciado com registros abrangentes.
  • Gerenciamento padronizado de CA e chaves: gerencie as CAs do cluster do GKE usando o Certificate Authority Service, delegando o gerenciamento de certificados a equipes específicas e aplicando políticas de CA de maneira abrangente. Além disso, gerencie as chaves de criptografia de disco do plano de controle usando o Cloud KMS para uma delegação de gerenciamento semelhante.

Disponibilidade da autoridade do plano de controle do GKE

As regiões e zonas em que você pode usar a autoridade do plano de controle do GKE dependem de você querer usar recursos específicos, da seguinte forma:

  • Para criptografar os discos de inicialização do plano de controle com uma chave de criptografia gerenciada pelo cliente, seu cluster precisa estar em uma das seguintes regiões:
    • asia-east1
    • asia-northeast1
    • asia-southeast1
    • europe-west1
    • europe-west4
    • us-central1
    • us-east1
    • us-east4
    • us-east5
    • us-south1
    • us-west1
    • us-west3
    • us-west4
  • Para usar os nós confidenciais do GKE com a autoridade do plano de controle do GKE, o cluster precisa estar em uma região que ofereça suporte ao modo confidencial para o Hyperdisk equilibrado.

Se você não usa esses recursos, pode usar a autoridade do plano de controle do GKE em qualquer localização Google Cloud .

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 a seguir. Você pode usar uma ou mais dessas funcionalidades 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 os registros de emissão de identidade no Cloud KMS e no serviço de CA para saber quando as identidades são criadas usando chaves e CAs que você gerencia. Use registros detalhados de uso da API do Kubernetes para rastrear o que essas identidades fazem no cluster.

Gerenciamento de chaves e credenciais

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

O GKE usa essas chaves e CAs em vez dos padrões Google Cloud para emitir e verificar identidades no cluster e criptografar dados nas 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:

  • Obedeça às regulamentações de privacidade e soberania de dados que exigem controle exclusivo sobre as chaves
  • Controle a criptografia de dados sensíveis críticos 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 o uso de chaves com suporte de hardware.

CAs autogerenciadas e chaves de conta de serviço

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

Você cria 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 são JSON Web Tokens (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. Normalmente, essa chave é a mesma que a de assinatura, mas é configurada separadamente para que você possa alternar as chaves com mais segurança.
  3. AC do cluster: emite certificados assinados para fins como solicitações de assinatura de certificado (CSRs) e comunicação do kubelet.
  4. CA de peer do etcd: emite certificados assinados para comunicação entre instâncias do etcd no cluster.
  5. CA da API etcd: emite certificados assinados para comunicação com o servidor da API etcd.
  6. CA 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. É possível usar esses registros para rastrear 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.

Criptografia do disco de inicialização e do etcd do plano de controle

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 vai criptografar o seguinte:

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

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

Opcionalmente, é possível usar suas próprias chaves de criptografia gerenciadas com o 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 backup Google Cloud interno do etcd 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 em vez disso.

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

Essa criptografia opcional adicional é 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. Você pode 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 a autoridade do plano de controle do GKE 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 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 ver 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 da Transparência no acesso.
  • Emissão e verificação de identidade: registros relacionados a identidades 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 no acesso: registros relacionados a conexões feitas com o plano de controle e ações realizadas no plano de controle por funcionários da 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 atividades suspeitas 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.
  • Saiba 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 CA Service. Use registros detalhados de uso da API Kubernetes para rastrear 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

Nesta seção, descrevemos outros métodos que podem ser usados para aumentar 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:

  • 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ós 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.

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

A seguir