Este documento explica as responsabilidades de segurança compartilhadas do Google e dos clientes doGoogle Cloud . Executar um aplicativo essencial para o negócio no Google Kubernetes Engine (GKE) requer que várias partes tenham responsabilidades diferentes. Embora este documento não seja uma lista completa, ele pode ajudar você a entender suas responsabilidades.
Este documento é destinado a especialistas em segurança que definem, regem e implementam políticas e procedimentos para proteger os dados de uma organização contra acesso não autorizado. Para saber mais sobre papéis comuns e exemplos de tarefas que mencionamos no conteúdo do Google Cloud , consulte Tarefas e funções de usuário comuns do GKE.
Responsabilidades do Google
- Proteger a infraestrutura subjacente, incluindo hardware, firmware, kernel, SO, armazenamento, rede e outros. Isso inclui criptografar dados em repouso por padrão, fornecer criptografia extra de disco gerenciada pelo cliente, fornecer criptografia de dados em trânsito usando hardware personalizado, colocar cabos de rede particular, proteger os data centers contra o acesso físico, proteger o carregador de inicialização e o kernel contra modificação usando nós protegidos e seguir as práticas de desenvolvimento de software seguras
- Aumentar a proteção e aplicar patches no sistema operacional dos nós, como o Container-Optimized OS ou Ubuntu. O GKE disponibiliza todos os patches dessas imagens. Se o upgrade automático estiver ativado ou se você estiver usando um canal de lançamento, essas atualizações serão implantadas automaticamente. Essa é a camada de SO abaixo de seu contêiner, não é a mesma do sistema operacional em execução nos seus contêineres
- Criar e operar a detecção de ameaças específicas do contêiner no kernel com o Container Threat Detection (cobrado separadamente pelo Security Command Center)
- Aumentar a proteção e aplicar patches em componentes do nó do Kubernetes. Todos os componentes gerenciados do GKE são atualizados
automaticamente quando você faz upgrade das versões de nós do GKE. Isso inclui o seguinte:
- Mecanismo de inicialização confiável compatível com vTPM para emitir certificados TLS do kubelet e rotação automática dos certificados
- Configuração do kubelet com mais proteção seguindo comparativos de mercado CIS
- Servidor de metadados do GKE para identidade da carga de trabalho
- Plug-in nativo da interface de rede do contêiner e Calico para NetworkPolicy do GKE
- Integrações de armazenamento do Kubernetes no GKE, como o driver CSI
- Agentes de geração de registros e monitoramento do GKE
- Aumento da segurança e aplicação de patches no plano de controle. O plano de controle inclui a VM do plano de controle, o servidor de API, o programador, o gerenciador do controlador, a AC do cluster, a emissão e a rotação do certificado TLS, o material da chave raiz da confiança, o autenticador e o autorizador do IAM, a configuração de geração de registros de auditoria, etcd e vários outros controladores. Todos os componentes do seu plano de controle são executados em instâncias do Compute Engine operadas pelo Google. Essas instâncias são locatário individual, o que significa que cada instância executa o plano de controle e os componentes dele para apenas um cliente
- Fornecer Google Cloud integrações para Connect, Identity and Access Management, Registros de auditoria do Cloud, Google Cloud Observability, Cloud Key Management Service, Security Command Center e outros.
- Restringir e registrar o acesso administrativo do Google aos clusters de clientes para fins de suporte contratual com a Transparência no acesso
Responsabilidades do cliente
- Manter as cargas de trabalho, incluindo o código do aplicativo, os arquivos de build, as imagens de contêiner, os dados, a política de IAM/controle de acesso baseado em papéis (RBAC, na sigla em inglês) e os contêineres e pods que você está executando
- Rotacionar as credenciais dos clusters.
- Mantenha os pools de nós padrão inscritos em upgrades automáticos.
- Nas seguintes situações, faça upgrade manual dos clusters e pools de nós
para corrigir vulnerabilidades nos cronogramas de aplicação de patch da sua organização:
- Os upgrades automáticos são adiados devido a fatores como políticas de manutenção.
- É necessário aplicar um patch antes que ele fique disponível no canal de lançamento selecionado. Para mais informações, consulte Executar versões de patch de um canal mais recente.
- Monitore o cluster e os aplicativos e responda a alertas e incidentes usando tecnologias como o painel de postura de segurança e a Google Cloud Observability.
- Fornecer ao Google detalhes ambientais quando solicitado para a solução de problemas
- Verifique se o Logging e o Monitoring estão ativados nos clusters. Se você não ativar o Logging e o Monitoring, e se a equipe de suporte não conseguir acessar esses registros, o suporte será disponibilizado da melhor maneira possível.
A seguir
- Leia a Visão geral de segurança do GKE.