Com a velocidade do desenvolvimento no Kubernetes, muitas vezes há novos recursos de segurança para você usar. Neste documento, descrevemos como aumentar a proteção dos seus clusters do GKE no VMware.
Este documento prioriza as mitigações de segurança de alto valor que exigem ação no momento da criação do cluster. Recursos menos críticos, configurações de segurança por padrão e recursos que podem ser ativados após a criação do cluster são mencionados posteriormente no documento. Para uma visão geral dos tópicos de segurança, consulte Segurança.
Lista de verificação
A lista de verificação de implantação a seguir destaca as práticas recomendadas para aumentar a proteção da implantação da plataforma de clusters do GKE. Para saber mais sobre cada prática, consulte as seções deste documento.
| Lista de verificação da implantação | Descrição |
|---|---|
| Controle de identidade e acesso | Usar privilégios de conta do vSphere: Contas de serviço seguras do Google Cloud: Configurar o OpenID Connect (OIDC): Usar namespaces do Kubernetes e RBAC para restringir o acesso: |
| Proteção de dados | Criptografar máquinas virtuais do vSphere: Gerenciar secrets: |
| Proteção de rede | Restringir o acesso à rede ao plano de controle e aos nós: Use políticas de rede para restringir o tráfego: |
| Segurança declarativa | Use o Policy Controller: |
| Manutenção | Faça upgrade do GKE Enterprise: Monitore boletins de segurança: |
| Como monitorar e gerar registros | Definir opções para geração de registros de cluster do GKE: |
Controle de identidade e acesso
Usar privilégios da conta do vSphere
A conta de usuário do vCenter que você usa para instalar o GKE no VMware precisa ter privilégios suficientes. Por exemplo, uma conta de usuário com o papel de administrador do vCenter tem privilégios para acesso completo a todos os objetos do vCenter e fornece um administrador de cluster do GKE no VMware com acesso total.
Recomendamos o princípio de privilégio mínimo, que concede apenas os privilégios necessários para instalar o GKE Enterprise. Definimos previamente o conjunto mínimo de privilégios necessário para executar a instalação, além dos comandos necessários para conceder essas permissões.
Proteger contas de serviço do Google Cloud
O GKE no VMware requer três contas de serviço do Google Cloud:
- Uma conta de serviço com permissão para acessar o software GKE no VMware. Você cria isso quando compra o GKE Enterprise.
- Uma conta de serviço de registro a ser usada pelo Connect para registrar clusters no GKE no VMware com o Google Cloud.
- Uma conta de serviço do Cloud Logging para coletar registros do cluster para uso no Cloud Logging.
Durante a instalação, você vincula os papéis de gerenciamento de identidade e acesso a essas contas de serviço. Esses papéis concedem privilégios específicos às contas de serviço dentro do projeto e podem ser gerados durante a instalação.
Configurar a autenticação para usuários do cluster
Para configurar a autenticação de usuários do cluster, use o OpenID Connect (OIDC) ou o Protocolo leve de acesso a diretórios (LDAP, na sigla em inglês).
Para mais informações, consulte o Serviço de identidade do GKE.
Usar namespaces do Kubernetes e RBAC para restringir o acesso
Para conceder às equipes acesso de privilégio mínimo ao Kubernetes, crie namespaces (em inglês) ou clusters específicos do ambiente do Kubernetes. Atribua centros de custo e rótulos apropriados a cada namespace para responsabilidade e estorno. Forneça aos desenvolvedores somente o nível de acesso aos namespaces necessários para implantar e gerenciar os aplicativos, especialmente na produção.
Mapeie as tarefas que os usuários precisam concluir no cluster e defina as permissões necessárias para concluir cada tarefa. Para conceder permissões no nível do cluster e do namespace, use o RBAC do Kubernetes.
Além das permissões das contas de serviço do Google Cloud usadas para instalar o GKE no VMware, o IAM não se aplica aos clusters do GKE no VMware.
Para mais informações, consulte a seguinte documentação:
Proteção de dados
Criptografar máquinas virtuais do vSphere
Os nós do cluster do GKE no VMware são executados em máquinas virtuais (VMs) no cluster do vSphere. O Google recomenda que você criptografe todos os dados em repouso. Para fazer isso no vSphere, siga o Guia de configuração e proteção de segurança do VMware vSphere 7 e as práticas recomendadas para criptografar VMs.
Isso precisa ser feito antes da instalação do GKE Enterprise.
Gerenciar secrets
Para fornecer uma camada extra de proteção para dados confidenciais, como os secrets do Kubernetes armazenados no etcd, configure um gerenciador de secrets integrado aos clusters do GKE no VMware.
Se você estiver executando cargas de trabalho em vários ambientes, talvez prefira uma solução que funcione para o Google Kubernetes Engine e o GKE no VMware. Se você optar por usar um gerenciador de secrets externos, como o HashiCorp Vault, configure-o antes de integrar seus clusters do GKE no VMware.
Há várias opções de gerenciamento de secrets:
- É possível usar os secrets do Kubernetes nativamente no GKE no VMware. Esperamos que os clusters usem a criptografia vSphere para as VMs, conforme descrito anteriormente, que fornece proteção básica de criptografia em repouso para secrets. Os secrets não recebem mais criptografia do que isso por padrão.
- É possível usar um gerenciador de secrets externo, como o HashiCorp Vault. Para autenticar no HashiCorp, use uma conta de serviço do Kubernetes ou do Google Cloud.
Para mais informações, consulte a seguinte documentação:
Proteção de rede
Restringir o acesso à rede ao plano de controle e aos nós
Limitar a exposição do plano de controle de cluster e nós à Internet. Essas opções não podem ser alteradas após a criação do cluster. Por padrão, os nós de cluster do GKE no VMware são criados usando endereços RFC 1918. A prática recomendada é não alterar isso. Implemente regras de firewall na rede local para restringir o acesso ao plano de controle.
Usar políticas de rede para restringir o tráfego
Por padrão, todos os serviços em um cluster do GKE no VMware podem se comunicar uns com os outros. Para informações sobre como controlar a comunicação de serviço a serviço conforme necessário para suas cargas de trabalho, consulte as seções a seguir.
Restringir o acesso à rede aos serviços dificulta muito a migração lateral dos invasores dentro do cluster, além de oferecer aos serviços alguma proteção contra negação de serviço acidental ou deliberada. Há duas maneiras recomendadas de controlar o tráfego:
- Para controlar o tráfego L7 aos endpoints dos aplicativos, use o Istio. Escolha essa opção se você tiver interesse em balanceamento de carga, autorização de serviço, limitação, cotas e métricas.
- Para controlar o tráfego L4 entre pods, use as políticas de rede (em inglês) do Kubernetes. Escolha essa opção se você estiver procurando a funcionalidade básica de controle de acesso exposta pelo Kubernetes.
É possível ativar a política de rede do Istio e do Kubernetes depois de criar os clusters do GKE no VMware. Use-os juntos, se necessário.
Para mais informações, consulte a seguinte documentação:
Segurança declarativa
Usar o Policy Controller
Os controladores de admissão (em inglês) do Kubernetes são plug-ins que controlam e aplicam a maneira como um cluster do Kubernetes é usado. Os controladores de admissão são uma parte importante da abordagem de defesa em profundidade para aumentar a proteção do cluster.
A prática recomendada é usar o Policy Controller. O controlador de políticas usa o framework de restrições de OPA (em inglês) para descrever e aplicar a política como CRDs. As restrições que você quer aplicar ao cluster são definidas em modelos de restrição, que são implantados nos clusters.
Para informações sobre como usar restrições do Policy Controller para conseguir muitas das mesmas proteções que PodSecurityPolicies, com a capacidade extra de testar suas políticas antes de aplicá-las, consulte Usando restrições para impor a segurança do pod.
Para mais informações, consulte a seguinte documentação:
Restringir a capacidade de automodificação das cargas de trabalho
Certas cargas de trabalho do Kubernetes, principalmente as cargas de trabalho do sistema, têm permissão para se automodificar. Por exemplo, algumas cargas de trabalho escalonam automaticamente na vertical. Embora seja conveniente, isso pode permitir que um invasor que já tenha comprometido um nó escalone ainda mais no cluster. Por exemplo, um invasor pode fazer com que uma carga de trabalho do nó se automodifique para ser executada como uma conta de serviço com mais privilégios que existe no mesmo namespace.
O ideal é que as cargas de trabalho não recebam permissão para se automodificar. Quando a automodificação for necessária, limite as permissões aplicando restrições do Gatekeeper ou do Policy Controller, como NoUpdateServiceAccount da biblioteca de código aberto do Gatekeeper, que fornece várias medidas de segurança úteis.
Quando você implanta políticas, geralmente é necessário permitir que os controladores que
gerenciam o ciclo de vida do cluster ignorem as políticas e os pipelines de
geração de registros e monitoramento. Isso é necessário para que os controladores possam fazer alterações
no cluster, como a aplicação de upgrades de cluster. Por exemplo, se você implantar
a política NoUpdateServiceAccount no GKE no VMware, será necessário definir os
seguintes parâmetros no Constraint:
parameters:
allowedGroups:
- system:masters
allowedUsers:
- system:serviceaccount:kube-system:monitoring-operator
- system:serviceaccount:kube-system:stackdriver-operator
- system:serviceaccount:kube-system:metrics-server-operator
- system:serviceaccount:kube-system:logmon-operator
Manutenção
Fazer upgrade do GKE Enterprise
O Kubernetes apresenta frequentemente novos recursos de segurança e fornece patches de segurança.
Você é responsável por manter seus clusters do GKE no VMware atualizados. Para cada versão, leia as notas da versão. Além disso, planeje atualizar para novos lançamentos de patches mensalmente e versões secundárias a cada três meses. Saiba como fazer upgrade dos clusters.
Você também é responsável por fazer upgrade e proteger a infraestrutura do vSphere:
- Estabeleça um processo para realizar patches e upgrades pontuais das suas VMs
- Fique por dentro dos avisos de segurança do VMware mais recentes
- Siga as orientações sobre como aplicar patches aos hosts.
Monitorar boletins de segurança
A equipe de segurança do GKE Enterprise publica boletins de segurança sobre vulnerabilidades de gravidade alta e crítica.
Esses boletins seguem um esquema de numeração de vulnerabilidade do Google Cloud comum e estão vinculados à página principal de boletins no Google Cloud e às notas da versão do GKE no VMware. Cada página de boletins de segurança tem um feed RSS no qual os usuários podem se inscrever para receber atualizações.
Quando a ação do cliente for necessária para resolver essas vulnerabilidades desse tipo, o Google entrará em contato com os clientes por e-mail. Além disso, o Google também pode entrar em contato com os clientes por meio de contratos de suporte por meio de canais de suporte.
Para mais informações, consulte a seguinte documentação:
Como monitorar e gerar registros
Definir opções para a geração de registros de clusters do GKE
O GKE no VMware inclui várias opções de geração de registros e monitoramento de cluster, incluindo serviços gerenciados baseados em nuvem, ferramentas de código aberto e compatibilidade validada com soluções comerciais de terceiros.
- Cloud Logging e Cloud Monitoring, ativados por agentes no cluster implantados com o GKE no VMware
- Configurações validadas com soluções de terceiros
Seja qual for a solução de geração de registros escolhida com base nos requisitos de negócios, recomendamos que você registre eventos e alertas relevantes para o serviço por um serviço centralizado de segurança e gerenciamento de eventos (SIEM, na sigla em inglês) para gerenciar incidentes de segurança.
Para mais informações, consulte a seguinte documentação:
- Geração de registros e monitoramento
- Como usar a geração de registros e o monitoramento
- Geração de registros e monitoramento de aplicativos
- Como monitorar clusters do Anthos no VMware com o Elastic Stack
- Coletar registros no GKE Enterprise com o Splunk Connect