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 clusters do Anthos em no VMware (GKE On-Prem).
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 Anthos. 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 controlador de política do Anthos Config Management: |
| Manutenção | Faça upgrade do Anthos: Monitorar boletins de segurança: |
| Como monitorar e gerar registros | Definir opções para geração de registros de clusters do Anthos: |
Controle de identidade e acesso
Usar privilégios da conta do vSphere
A conta de usuário do vCenter usada para instalar clusters do Anthos no VMware precisa ter privilégios suficientes. Por exemplo, uma conta de usuário com o papel Administrador do vCenter tem privilégios de acesso completo a todos os objetos do vCenter e fornece um administrador de clusters do anthos no VMware com acesso total.
Recomendamos o princípio do menor privilégio, concedendo apenas os privilégios necessários para instalar o Anthos. Predefinemos 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
Os clusters do Anthos no VMware exigem três contas de serviço do Google Cloud:
- Uma conta de serviço permitida para acessar os clusters do Anthos no software VMware. Você a cria ao comprar o Anthos.
- Uma conta de serviço de registro a ser usada por Conectar para registrar clusters do Anthos em clusters do 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 o OpenID Connect
Só é possível configurar a autenticação no momento da criação do cluster. Para configurar a autenticação do usuário para os clusters, use o OpenID Connect (OIDC).
Os clusters do Anthos no VMware são compatíveis com o OIDC como um dos mecanismos de autenticação para interagir com o servidor da API Kubernetes de um cluster de usuário. O OICD permite gerenciar o acesso aos clusters do Kubernetes usando os procedimentos padrão na organização para criar, ativar e desativar contas de usuário.
Para suporte específico ao OIDC, consulte a seguinte documentação:
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 para contas de serviço do Google Cloud usadas para instalar clusters do Anthos no VMware, o IAM não se aplica a clusters do Anthos em clusters do VMware.
Para mais informações, consulte a seguinte documentação:
- Contas de serviço e chaves
- Visão geral dos tópicos de instalação avançada
- Privilégios da conta de usuário do vCenter
Proteção de dados
Criptografar máquinas virtuais do vSphere
Os clusters do Anthos em nós do cluster do 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 PDF de segurança do VMware e as práticas recomendadas para criptografar VMs.
Isso precisa ser feito antes da instalação do Anthos.
Gerenciar secrets
Para fornecer uma camada extra de proteção para dados confidenciais, como os secrets do Kubernetes armazenados no etcd (em inglês), configure um gerenciador de secrets integrado aos clusters do Anthos em clusters do VMware.
Se você estiver executando cargas de trabalho em vários ambientes, talvez prefira uma solução que funcione para clusters do Google Kubernetes Engine e do Anthos no VMware. Se você optar por usar um gerenciador de secrets externos, como o HashiCorp Vault, configure-o antes de integrar seus clusters do Anthos em clusters do VMware.
Há várias opções de gerenciamento de secrets:
- É possível usar os secrets do Kubernetes nativamente nos clusters do Anthos 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 clusters do Anthos em nós do cluster do 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 clusters do Anthos no cluster do VMware podem se comunicar entre si. 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 seus clusters do Anthos nos clusters do VMware. Use-os juntos, se necessário.
Para mais informações, consulte a seguinte documentação:
Segurança declarativa
Usar o controlador de políticas do Anthos Config Management
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 controlador de políticas do Anthos Config Management. 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 em clusters do Anthos 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 Anthos
O Kubernetes apresenta frequentemente novos recursos de segurança e fornece patches de segurança.
Você é responsável por manter seus clusters do Anthos nos clusters 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
- Confira os avisos em inglês de segurança da VMware mais recentes.
- Siga as orientações em inglês sobre como aplicar patches nos hosts.
Monitorar boletins de segurança
A equipe de segurança do Anthos publica boletins de segurança para vulnerabilidades de gravidade alta e crítica.
Estes boletins seguem um esquema de numeração de vulnerabilidade comum do Google Cloud e estão vinculados na página principal de boletins do Google Cloud e nas notas da versão dos clusters do Anthos 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 geração de registros de clusters do Anthos
Os clusters do Anthos no VMware incluem várias opções para geração de registros e monitoramento de clusters, incluindo serviços gerenciados baseados em nuvem, ferramentas de código aberto e validação de compatibilidade com soluções comerciais de terceiros.
- Cloud Logging e Cloud Monitoring, ativados por agentes no cluster implantados com os clusters do Anthos no VMware
- Prometheus e Grafana, desativados por padrão
- 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 Anthos com o Splunk Connect