Acerca da autoridade do plano de controlo do GKE

.

Esta página descreve as opções que o Google Kubernetes Engine (GKE) oferece para melhorar a visibilidade e o controlo sobre a segurança do plano de controlo gerido. Estas opções são coletivamente denominadas autoridade do plano de controlo do GKE. Esta página destina-se a líderes de segurança da informação, administradores de conformidade e analistas que pretendem cumprir necessidades rigorosas de privacidade e segurança para o tratamento de dados confidenciais.

Acerca das funcionalidades de autoridade do plano de controlo do GKE

No GKE, Google Cloud a configuração de segurança do plano de controlo é totalmente gerida, incluindo a encriptação do armazenamento em repouso e a configuração das chaves e das autoridades de certificação (ACs) que assinam e validam as credenciais nos seus clusters. Os nós do plano de controlo dos clusters do GKE existem em projetos que o GKE gerem. Google Cloud Para ver detalhes sobre o que Google Cloud faz, consulte o artigo Responsabilidade partilhada do GKE.

A autoridade do plano de controlo do GKE é um conjunto opcional de visibilidade e capacidades de controlo que lhe permitem validar e gerir aspetos específicos destes nós do plano de controlo totalmente geridos. Estas capacidades são ideais se tiver requisitos como os seguintes:

  • Opera num setor altamente regulamentado, como o setor financeiro, de cuidados de saúde ou governamental, com requisitos de conformidade específicos
  • Processa dados confidenciais que têm requisitos rigorosos de segurança e encriptação
  • Quer uma visibilidade melhorada sobre o GKE para aumentar a sua confiança ao executar cargas de trabalho críticas
  • Tem de cumprir requisitos específicos de conformidade ou auditoria relacionados com a encriptação de dados, a integridade do software ou o registo
  • Tem cargas de trabalho altamente sensíveis que processam dados críticos e quer ter visibilidade da encriptação e do acesso a esses dados
  • Quer aplicar políticas de segurança personalizadas que cumpram requisitos organizacionais ou regulamentares específicos
  • Quer um nível melhorado de transparência e visibilidade nos seus ambientes do GKE, especialmente no que diz respeito às ações que oGoogle Cloud plano de controlo realiza

Vantagens da autoridade do plano de controlo do GKE

As capacidades de autoridade do plano de controlo do GKE são ideais em ambientes altamente regulamentados que têm políticas de segurança rigorosas ou requisitos de auditoria rigorosos. A utilização destas capacidades concede vantagens como as seguintes:

  • Visibilidade e controlo melhorados: use capacidades adicionais de visibilidade, controlo e encriptação para o seu plano de controlo do GKE.
  • Conformidade simplificada: cumpra os requisitos regulamentares e da indústria com registos de auditoria detalhados e políticas de segurança personalizáveis.
  • Maior confiança e transparência: obtenha estatísticas sobre as ações que a Google Cloud realiza no plano de controlo ao resolver casos de apoio técnico ao cliente.
  • Mitigação de riscos: detete e responda proativamente a potenciais ameaças ao plano de controlo gerido com registos abrangentes.
  • Gestão de chaves e ACs padronizada: faça a gestão das ACs do cluster do GKE através do serviço de autoridade de certificação, o que lhe permite delegar a gestão de certificados em equipas específicas e aplicar políticas de AC de forma abrangente. Além disso, pode gerir as chaves de encriptação de disco do plano de controlo com o Cloud KMS para uma delegação de gestão semelhante.

Disponibilidade da autoridade do plano de controlo do GKE

As regiões e as zonas nas quais pode usar a autoridade do plano de controlo do GKE dependem de querer usar também funcionalidades específicas, da seguinte forma:

  • Para encriptar os discos de arranque do plano de controlo com uma chave de encriptação gerida pelo cliente, o cluster tem de estar numa 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 nós do GKE confidenciais com a autoridade do plano de controlo do GKE, o seu cluster tem de estar numa região que suporte o modo confidencial para o Hyperdisk Balanced.

Se não usar estas funcionalidades, pode usar a autoridade do plano de controlo do GKE em qualquer Google Cloud localização.

Como funciona a autoridade do plano de controlo do GKE

As capacidades que pode usar com o plano de controlo estão categorizadas com base no tipo de controlo que quer, da seguinte forma. Pode usar uma ou mais destas capacidades com base nos seus requisitos específicos.

  • Gestão de chaves e credenciais: controle as chaves que o GKE usa para encriptar dados em repouso no plano de controlo e para emitir e validar identidades no cluster.
  • Aceda aos registos e aos registos de emissão de identidades: use registos da rede, da VM e da Transparência de acesso para validar o acesso ao plano de controlo do GKE através de várias origens. Use os registos de emissão de identidades no Cloud KMS e no serviço de AC para ver quando as identidades são criadas através de chaves e ACs que gere. Use registos de utilização detalhados da API Kubernetes para acompanhar o que essas identidades fazem no cluster.

Gestão de chaves e credenciais

Por predefinição, Google Cloud faz a gestão das chaves e das ACs nos seus clusters do GKE. Opcionalmente, pode usar o Cloud KMS e o serviço de AC para configurar as suas próprias chaves e ACs, que usa depois quando cria um novo cluster.

O GKE usa estas chaves e ACs em vez das predefinições para emitir e validar identidades no seu cluster e para encriptar dados nas VMs do plano de controlo. Google CloudManter o controlo sobre a emissão de identidade e as chaves de encriptação de dados pode ajudar a fazer o seguinte:

  • Cumprir os regulamentos de privacidade e soberania dos dados que exigem o controlo exclusivo das chaves
  • Controle a encriptação de dados confidenciais críticos no Kubernetes através da gestão das suas próprias chaves de encriptação
  • Personalize a sua estratégia de encriptação de dados com base nas políticas e nos requisitos da sua organização, como os requisitos para usar chaves suportadas por hardware.

ACs autogeridas e chaves de contas de serviço

Pode configurar o plano de controlo do GKE para usar chaves do Cloud KMS e ACs do serviço de ACs que gere. O GKE usa estes recursos para emitir e validar identidades no seu 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.

Cria os seguintes recursos para o GKE usar quando emitir identidades:

  1. Chaves de assinatura da conta de serviço: assinam os tokens de portador da conta de serviço do Kubernetes para contas de serviço no cluster. Estes tokens de autorização são tokens Web JSON (JWTs) que facilitam a comunicação do pod com o servidor da API Kubernetes.
  2. Chaves de validação da conta de serviço: validam os JWTs da conta de serviço do Kubernetes. Normalmente, esta chave é igual à chave de assinatura, mas é configurada separadamente para que possa rodar as chaves de forma mais segura.
  3. AC do cluster: emitir certificados assinados para fins como pedidos de assinatura de certificados (CSRs) e comunicação kubelet.
  4. CA de pares do etcd: emite certificados assinados para 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. 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, vê os registos de auditoria correspondentes no Cloud Logging, que pode usar para acompanhar as identidades emitidas ao longo do respetivo ciclo de vida.

Para saber mais, consulte o artigo Execute as suas próprias autoridades de certificação e chaves de assinatura no GKE.

Encriptação do disco de arranque e do etcd do plano de controlo

Por predefinição, o GKE encripta o disco de arranque de uma VM do plano de controlo. Se o plano de controlo executar instâncias da base de dados etcd, o GKE também encripta o seguinte:

  • O disco que armazena os dados do etcd.
  • A Google Cloud cópia de segurança operacional interna do etcd.

Esta encriptação predefinida usa chaves de encriptação que a Google Google Cloud gere. Para ver detalhes sobre esta encriptação predefinida, consulte o artigo Encriptação predefinida em repouso.

Opcionalmente, pode usar as suas próprias chaves de encriptação que gere com o Cloud KMS para encriptar os seguintes recursos:

  • Disco de arranque do plano de controlo: o disco do Compute Engine que cada VM do plano de controlo usa para arrancar.
  • Disco etcd: o disco do Compute Engine que está associado a cada VM do plano de controlo e armazena dados para instâncias etcd no cluster.

  • Cópia de segurança operacional interna do etcd: a Google Cloud cópia de segurança interna do etcd que é usada para fins operacionais, como a recuperação de desastres.

    Esta cópia de segurança é uma medida de emergência interna ao Google Cloud. Se quiser fazer uma cópia de segurança e restaurar os seus clusters, use a cópia de segurança do GKE.

Para ver instruções, consulte o artigo Criptografe os discos de arranque do etcd e do plano de controlo.

Esta encriptação opcional adicional é ideal se tiver de cumprir requisitos regulamentares ou de conformidade específicos relacionados com o controlo dos meios de encriptação no painel de controlo do cluster. Pode usar as suas próprias chaves separadamente para encriptar os discos de arranque e os discos de armazenamento dos nós de trabalho no seu cluster. Para ver detalhes, consulte o artigo Use chaves de encriptação geridas pelo cliente (CMEK).

Quando usa a autoridade do plano de controlo do GKE para encriptar os discos de arranque do plano de controlo, as VMs do plano de controlo do GKE usam automaticamente o modo confidencial para o Hyperdisk Balanced nos discos de arranque. Esta configuração não altera os discos de arranque predefinidos dos nós de trabalho.

Rotação de credenciais geridas pelo cliente

Com a autoridade do plano de controlo do GKE, pode configurar clusters para usar CAs e chaves geridas pelo cliente em vez dos recursos geridos pela Google que o GKE usa por predefinição. Uma rotação de credenciais é uma operação que realiza para atualizar um ou mais destes recursos num cluster. Pode fazer uma rotação de credenciais por motivos como evitar a expiração da AC ou agir em conformidade com os requisitos de gestão de credenciais da sua organização.

Para fazer uma rotação de credenciais para um cluster que usa a autoridade do plano de controlo do GKE, cria novas ACs, chaves de assinatura e chaves de encriptação. Em seguida, atualiza o cluster para usar esses novos recursos.

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

Registos de acesso e registos de emissão de identidade

Pode ver registos no Logging para todos os eventos relacionados com o acesso e a identidade no plano de controlo, incluindo os seguintes eventos:

  • Acesso direto: os registos relacionados com tentativas de acesso direto (como SSH) aos nós do plano de controlo do GKE permitem-lhe verificar se os registos SSH da VM e as ligações de rede da VM correspondem aos registos SSH nos registos da Transparência de acesso.
  • Emissão e validação de identidades: registos relacionados com identidades que foram emitidas através de ACs e chaves que gere no CA Service e no Cloud KMS.
  • Utilização de identidades no Kubernetes: registos relacionados com as ações que identidades específicas realizam no servidor da API Kubernetes.
  • Transparência de acesso: registos relacionados com as ligações feitas ao plano de controlo e as ações realizadas no plano de controlo pelo Google Cloud pessoal.

Estes registos podem ajudar a fazer o seguinte:

  • Manter trilhos de auditoria abrangentes de todos os eventos de acesso ao plano de controlo e de identidade para conformidade e segurança.
  • Além das proteções Google integradas, pode criar a sua própria monitorização para identificar e investigar qualquer atividade suspeita no plano de controlo.
  • Verifique se apenas entidades autorizadas acedem e interagem com o seu cluster do GKE, o que melhora o seu comportamento de segurança.
  • Veja quando as identidades são criadas através de chaves e ACs que gere com os registos de emissão de identidades no Cloud KMS e no CA Service. Use registos de utilização detalhados da API Kubernetes para monitorizar o que essas identidades fazem no cluster.

Os documentos seguintes mostram como ver e processar os vários tipos de registos do plano de controlo:

Recursos adicionais sobre a segurança do plano de controlo

Esta secção descreve outros métodos que pode usar para melhorar a sua confiança na segurança do plano de controlo. Não precisa de usar a autoridade do plano de controlo do GKE para usar os seguintes recursos:

  • 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 trabalho. Pode validar se as suas VMs usam imagens do SO com VSAs correspondentes e validar a integridade de 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.

  • Medidas de segurança do plano de controlo incorporadas: o GKE executa várias medidas de reforço no plano de controlo gerido. Para saber mais, consulte o artigo Segurança do plano de controlo.

O que se segue?