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 locais no GKE.
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 que você usa para instalar o GKE On-Prem precisa ter privilégios suficientes. Por exemplo, uma conta de usuário que recebe o papel de administrador do vCenter tem privilégios para acesso total a todos os objetos do vCenter e fornece um administrador de cluster local do GKE com acesso total.
Recomendamos o princípio do menor privilégio, concedendo apenas os privilégios necessários para instalar o Anthos. 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 On-Prem precisa de quatro contas de serviço do Google Cloud:
- Uma conta de serviço com permissão para acessar o software GKE On-Prem. Você a cria ao comprar o Anthos.
- Uma conta de serviço de registro a ser usada pelo Connect para registrar clusters no GKE On-Prem com o Google Cloud.
- Uma conta de serviço de conexão que será usada pelo Connect para estabelecer uma conexão entre os clusters do GKE On-Prem e 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).
O GKE On-Prem é compatível 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 das contas de serviço do Google Cloud usadas para instalar o GKE On-Prem, o IAM não se aplica aos clusters do GKE On-Prem.
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 nós do cluster do GKE On-Prem 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 GKE On-Prem.
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 On-Prem. Se você optar por usar um gerenciador de secrets externos, como o HashiCorp Vault, configure-o antes de integrar seus clusters locais do GKE.
Há várias opções de gerenciamento de secrets:
- É possível usar os secrets do Kubernetes nativamente no GKE On-Prem. 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 On-Prem 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 On-Prem 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 On-Prem. 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:
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 GKE On-Prem 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.
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. 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
O GKE On-Prem 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 On-Prem
- 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