Aprovada pela equipe de ação de segurança cibernética do Google.
Veja neste documento controles que podem ser usados para ajudar a configurar e proteger os clusters do Google Kubernetes Engine (GKE) que hospedam aplicativos personalizados distribuídos por locatários terceiros. Este documento faz parte de uma solução de blueprints composta de:
- um guia dos controles que você implementa (este documento);
- Um
repositório do GitHub
com os seguintes diretórios:
terraform: contém o código do Terraform usado para criar a infraestrutura e os recursos no nível do projeto. Esse código também instala os componentes do Anthos no cluster.configsync: contém os recursos e as configurações no nível do cluster que são aplicados ao cluster do GKE.tenant-config-pkg: um pacote kpt que pode ser usado como modelo para configurar novos locatários no cluster do GKE.
Este documento é destinado a equipes que administram clusters do GKE. É necessário ter conhecimento sobre o GKE e o Kubernetes.
Neste documento, pressupomos que você já tenha configurado um conjunto de base dos controles de segurança para proteger sua infraestrutura em nuvem, como os controles descritos no Guia de bases de segurança do Google Cloud. O blueprint ajuda a adicionar mais camadas aos controles de segurança atuais para ajudar a proteger os clusters do GKE.
Arquitetura
O diagrama a seguir descreve a arquitetura criada com esse blueprint:
Conforme o diagrama anterior, o blueprint ajuda a criar e configurar os seguintes componentes de infraestrutura:
- Uma sub-rede e uma rede de nuvem privada virtual (VPC).
- Um cluster particular do GKE. Os nós do cluster estão isolados da Internet.
- Dois pools de nós do GKE. Você cria um pool de nós dedicado para hospedar exclusivamente recursos e aplicativos de locatários. Outros recursos de cluster são hospedados no pool de nós padrão.
- Regras de firewall da VPC. Você cria regras de referência que se aplicam a todos os nós do cluster. Você cria outras regras que se aplicam apenas aos nós do pool do locatário. Essas regras de firewall limitam a saída dos nós de locatário.
- O Cloud NAT, para permitir a saída dos nós do cluster para a Internet.
- Regras do Cloud DNS configuradas para ativar o Acesso privado do Google, de modo que os aplicativos no cluster possam acessar as APIs do Google sem passar pela Internet.
- Contas de serviço usadas pelos nós e aplicativos do cluster.
Aplicativos
O diagrama a seguir mostra os recursos criados no nível do cluster e configurados com o blueprint.
Conforme o diagrama anterior, no blueprint, você usa o seguinte para criar e configurar os recursos no nível do cluster:
- Config Sync do Anthos Config Management, para sincronizar a configuração e as políticas de cluster de um repositório Git.
- Policy Controller do Anthos Config Management, para aplicar políticas a recursos no cluster.
- Anthos Service Mesh, para controlar e ajudar a proteger o tráfego de rede.
- Um namespace dedicado para aplicativos e recursos de locatário.
- Políticas e controles aplicados ao namespace de locatário, incluindo políticas de rede e políticas de malha de serviço.
Como entender os controles de segurança necessários
Nesta seção, vamos discutir os controles aplicados com o blueprint para ajudar a proteger o cluster do GKE.
Segurança aprimorada dos clusters do GKE
Como criar clusters de acordo com as práticas recomendadas de segurança.
O blueprint ajuda a criar um cluster do GKE que implementa as seguintes configurações de segurança:
- Limitar a exposição dos nós do cluster e do plano de controle à Internet criando um cluster particular do GKE com redes autorizadas.
- Usar
nós protegidos
por uma imagem de nó com aumento da proteção junto com o
ambiente de execução
containerd. - Aumentar o isolamento de cargas de trabalho de locatários usando o GKE Sandbox.
- Criptografar secrets do cluster na camada do aplicativo.
Saiba mais sobre as configurações de segurança do GKE em Como aumentar a segurança do cluster.
Regras de firewall da VPC
Como restringir o tráfego entre máquinas virtuais
As regras de firewall da nuvem privada virtual (VPC) determinam qual tráfego é permitido de ou para VMs do Compute Engine. As regras permitem filtrar o tráfego na granularidade da VM, dependendo dos atributos da Camada 4 (em inglês).
Crie um cluster do GKE com as regras de firewall padrão do cluster do GKE. Essas regras de firewall permitem a comunicação entre os nós de cluster e o plano de controle do GKE, bem como entre nós e pods no cluster.
Aplique regras de firewall adicionais aos nós do pool do locatário. Essas regras de firewall restringem o tráfego de saída dos nós de locatário. Essa abordagem permite aumentar o isolamento dos nós de locatário. Por padrão, todo o tráfego de saída dos nós de locatário é negado. Todas as saídas obrigatórias precisam ser explicitamente configuradas. Por exemplo, você usa o blueprint para criar regras de firewall que permitem a saída dos nós de locatário para o plano de controle do GKE e para as APIs do Google usando o Acesso privado do Google. As regras de firewall são direcionadas aos nós de locatário que usam a conta de serviço do pool do locatário.
Namespaces
Como rotular recursos que precisam usar as mesmas políticas
Os namespaces permitem fornecer um escopo para os recursos relacionados em um cluster, por exemplo, pods, serviços e controladores de replicação. Ao usar namespaces, é possível delegar a responsabilidade de administração dos recursos relacionados como uma unidade. Portanto, os namespaces são essenciais para a maioria dos padrões de segurança.
Os namespaces são um recurso importante para o isolamento do plano de controle. No entanto, eles não fornecem isolamento de nós, de plano de dados ou de rede.
Uma abordagem comum é criar namespaces para aplicativos individuais. Por
exemplo, é possível criar o namespace myapp-frontend para o componente de IU
de um aplicativo.
O blueprint ajuda você a criar um namespace dedicado para hospedar os apps de terceiros. O namespace e os recursos dele são tratados como locatários em seu cluster. Aplique políticas e controles ao namespace para limitar o escopo de recursos no namespace.
Políticas de rede
Como aplicar o fluxo de tráfego de rede nos clusters
As políticas de rede aplicam fluxos de tráfego de rede da camada 4 usando regras de firewall no nível do pod. As políticas de rede têm escopo para um namespace.
No blueprint, você aplica políticas de rede ao namespace de locatário que hospeda os aplicativos de terceiros. Por padrão, a política de rede nega todo o tráfego com origem e destino em pods do namespace. Qualquer tráfego obrigatório precisa ser explicitamente incluído na lista de permissões. Por exemplo, as políticas de rede no blueprint permitem explicitamente o tráfego para os serviços necessários do cluster, como o DNS interno do cluster e o plano de controle do Anthos Service Mesh.
Config Sync
Como aplicar configurações aos clusters do GKE
O Config Sync mantém os clusters do GKE sincronizados com as configurações armazenadas em um repositório do Git. O repositório do Git funciona como a única fonte de verdade para as políticas e a configuração do cluster. O Config Sync é declarativo. Ele verifica continuamente o estado do cluster e aplica o estado declarado no arquivo de configuração para aplicar as políticas, o que ajuda a evitar desvios de configuração.
Instale o Config Sync no cluster do GKE. Configure o Config Sync para sincronizar as configurações e as políticas do cluster no repositório do GitHub associado ao blueprint. Os recursos sincronizados incluem:
- A configuração do Anthos Service Mesh no nível do cluster
- As políticas de segurança no nível do cluster
- A configuração e a política no nível do namespace de locatário, incluindo políticas de rede, contas de serviço, regras de RBAC e a configuração do Anthos Service Mesh
Policy Controller
Como aplicar a conformidade com as políticas
O Anthos Policy Controller é um controlador de admissão dinâmico do Kubernetes que aplica políticas baseadas em definições de recursos personalizados (CRD, na sigla em inglês) executadas pelo Open Policy Agent (OPA).
Os controladores de admissão são plug-ins do Kubernetes que interceptam solicitações ao servidor da API Kubernetes antes da permanência de um objeto, mas após a autenticação e autorização da solicitação. É possível usar controladores de admissão para limitar o uso de um cluster.
Instale o Policy Controller no cluster do GKE. O blueprint inclui exemplos de políticas que ajudam a proteger o cluster. Aplique automaticamente as políticas ao cluster usando o Config Sync. Aplique as seguintes políticas:
- Políticas selecionadas para ajudar a aplicar a segurança do pod. Por exemplo, você aplica políticas que impedem os pods de executarem contêineres privilegiados e que exigem um sistema de arquivos raiz somente leitura.
- Políticas da biblioteca de modelos do Policy Controller. Por exemplo, você aplica uma política que não permite serviços com o tipo NodePort.
Anthos Service Mesh
Como gerenciar comunicações seguras entre serviços
O Anthos Service Mesh ajuda você a monitorar e gerenciar uma malha de serviço baseada no Istio. Uma malha de serviço é uma camada de infraestrutura que ajuda a criar uma comunicação gerenciada, observável e segura em todos os seus serviços.
O Anthos Service Mesh ajuda a simplificar o gerenciamento de comunicações seguras entre serviços das seguintes maneiras:
- Gerenciar autenticação e criptografia de tráfego (protocolos compatíveis no cluster usando comunicação de camada de transporte mútuo [mTLS, na sigla em inglês]). O Anthos Service Mesh gerencia o provisionamento e a rotação de chaves e certificados mTLS para cargas de trabalho do Anthos sem interromper as comunicações. A rotação regular de chaves mTLS é uma prática recomendada de segurança que ajuda a reduzir a exposição em caso de ataque.
- Permite que você configure políticas de segurança de rede com base na identidade do serviço, e não no endereço IP de pares na rede. O Anthos Service Mesh é usado para configurar políticas de controle de acesso com reconhecimento de identidade (firewall) que permitem criar políticas de segurança independentes do local da rede da carga de trabalho. Essa abordagem simplifica o processo de configuração das políticas de comunicações de serviço a serviço.
- Permite que você configure políticas que concedem acesso a determinados clientes.
O blueprint ajuda você a instalar o Anthos Service Mesh no cluster. Configure o namespace de locatário para a injeção automática de proxy sidecar. Essa abordagem garante que os aplicativos no namespace do locatário façam parte da malha. Configure automaticamente o Anthos Service Mesh com o Config Sync. Configure a malha para fazer o seguinte:
- Aplicar a comunicação mTLS entre os serviços na malha.
- Limitar o tráfego de saída da malha apenas para hosts conhecidos.
- Limitar a comunicação autorizada entre os serviços na malha. Por exemplo, os aplicativos no namespace do locatário só podem se comunicar com aplicativos que estejam no mesmo namespace ou tenham um conjunto de hosts externos conhecidos.
- Encaminhar todo o tráfego de saída por um gateway de malha em que é possível aplicar outros controles de tráfego.
Afinidades e taints de nós
Como controlar a programação da carga de trabalho
Os taints de nós e a afinidade de nós são mecanismos do Kubernetes que permitem influenciar na programação dos pods nos nós do cluster.
Os nós com taint repelem pods. O Kubernetes não vai programar um pod em um nó com taint, a menos que tenha uma tolerância para o taint. Use taints de nó para reservar nós para uso somente por determinadas cargas de trabalho ou locatários. Os taints e as tolerâncias costumam ser usados em clusters multilocatários. Saiba mais na documentação sobre nós dedicados com taints e tolerâncias.
A afinidade de nós permite restringir pods a nós com rótulos específicos. Se um pod tiver um requisito de afinidade de nós, o Kubernetes não o programará em um nó, a menos que o nó tenha um rótulo que corresponda a esse requisito. É possível usar a afinidade de nós para garantir que os pods sejam programados nos nós apropriados.
Use taints e afinidade de nós juntos para garantir que os pods da carga de trabalho do locatário sejam programados exclusivamente em nós reservados para o locatário.
O blueprint ajuda a controlar a programação de aplicativos do locatário das seguintes maneiras:
- Criando um pool de nós do GKE dedicado ao locatário. Cada nó no pool tem um taint relacionado ao nome do locatário.
- Aplicando automaticamente a tolerância e a afinidade de nós apropriadas a qualquer pod que tenha o namespace de locatário como destino. Aplique a tolerância e a afinidade usando as mutações do Policy Controller.
Privilégio mínimo
Como limitar o acesso a recursos de cluster e de projeto
É uma prática recomendada de segurança adotar um princípio de privilégio mínimo para os projetos e recursos do Google Cloud, como os clusters do GKE. Assim, os aplicativos executados no cluster, bem como os desenvolvedores e operadores que o usam, têm apenas o conjunto mínimo de permissões necessárias.
O blueprint ajuda a usar contas de serviço com privilégio mínimo das seguintes maneiras:
- Cada pool de nós do GKE recebe a própria conta de serviço. Por exemplo, os nós no pool do locatário usam uma conta de serviço dedicada a esses nós. As contas de serviço dos nós são configuradas com as permissões mínimas necessárias.
- O cluster usa a Identidade da carga de trabalho para associar contas de serviço do Kubernetes a contas de serviço do Google. Dessa forma, os aplicativos do locatário podem receber acesso limitado a qualquer API necessária do Google sem fazer o download nem armazenar uma chave de conta de serviço. Por exemplo, é possível conceder à conta de serviço permissões para ler dados de um bucket do Cloud Storage.
O blueprint ajuda a restringir o acesso aos recursos do cluster das seguintes maneiras:
- Você cria um papel RBAC do Kubernetes de amostra com permissões limitadas para gerenciar aplicativos. É possível conceder esse papel aos usuários e grupos que operam os aplicativos no namespace do locatário. Assim, esses usuários só têm permissões para modificar recursos do aplicativo no namespace do locatário. Eles não têm permissões para modificar recursos no nível do cluster ou configurações de segurança confidenciais, como as políticas do Anthos Service Mesh.
Resumo geral
Para implementar a arquitetura descrita neste documento, faça o seguinte:
- Determine se você vai implantar o blueprint em conjunto com o blueprint de bases de segurança ou sem ele. Se você optar por não implantar o blueprint de bases de segurança, verifique se o ambiente tem uma referência de segurança semelhante.
- Leia o arquivo Readme do blueprint e verifique se você atende a todos os pré-requisitos.
- No ambiente de teste, implante uma instância dessa arquitetura. Como parte do processo de teste, faça o seguinte:
- Implante o blueprint no ambiente de produção.
- Adicione mais locatários ao cluster.
A seguir
- Leia o Guia de bases de segurança do Google Cloud.
- Leia o Guia para aumentar a proteção do GKE.
Leia sobre aprendizado federado no Google Cloud
Saiba mais sobre as práticas recomendadas para o uso de gateways de saída do Anthos Service Mesh no GKE.