Segurança

Nesta página, você conhecerá os recursos de segurança incluídos no GKE no VMware, incluindo cada camada da infraestrutura e como configurar esses recursos para atender às suas necessidades.

Visão geral

O GKE em VMware oferece vários recursos para ajudar a proteger as cargas de trabalho, incluindo o conteúdo da imagem do contêiner, o ambiente de execução do contêiner, a rede do cluster e o acesso ao servidor da API do cluster.

É melhor adotar uma abordagem em camadas para proteger clusters e cargas de trabalho. É possível aplicar o princípio do menor privilégio (em inglês) ao nível de acesso fornecido aos usuários e cargas de trabalho. Talvez seja necessário fazer concessões para permitir o nível certo de flexibilidade e segurança.

Autenticação e autorização

Você se autentica nos clusters do GKE em VMware usando o OpenID Connect (OIDC) ou um token da conta de serviço do Kubernetes por meio do Console do Cloud.

Para configurar um acesso mais granular aos recursos do Kubernetes no nível do cluster ou nos namespaces do Kubernetes, use o controle de acesso baseado em papéis (RBAC, na sigla em inglês) do Kubernetes. O RBAC permite criar políticas detalhadas que definem quais operações e recursos você quer permitir que usuários e contas de serviço acessem. Com o RBAC, é possível controlar o acesso de qualquer identidade validada fornecida.

Para simplificar e agilizar ainda mais sua estratégia de autenticação e autorização do Kubernetes Engine, o GKE em VMware desativa o controle de acesso baseado em atributos (ABAC) legado.

Segurança do plano de controle

Os componentes do plano de controle incluem o programador, os controladores e o servidor da API Kubernetes, além do banco de dados etcd (em inglês) em que a configuração do Kubernetes é mantida. Já no Kubernetes Engine, os componentes do plano de controle do Kubernetes são gerenciados e mantidos pelo Google, e os administradores locais gerenciam os componentes do plano de controle no GKE no VMware.

No GKE em VMware, os componentes do plano de controle são executados na rede corporativa. É possível proteger o servidor da API do GKE em VMware com as políticas e os firewalls da sua rede corporativa. Também é possível atribuir um endereço IP particular ao servidor da API e limitar o acesso ao endereço particular.

Toda a comunicação no GKE em VMware é feita por canais TLS, que são regidos por três autoridades de certificação (CAs): etcd, cluster e org:

  • A CA etcd protege a comunicação do servidor da API com as réplicas do etcd e também o tráfego entre as réplicas do etcd. Essa CA é autoassinada.
  • A CA cluster protege a comunicação entre o servidor da API e todos os clientes internos da API Kubernetes (kubelets, controladores, programadores). Essa CA é autoassinada.
  • A CA org é uma CA externa usada para exibir a API Kubernetes para usuários externos. Você gerencia essa CA.

Para planos de controle do administrador, as chaves são armazenadas no nó (em inglês) do plano de controle. Para clusters de usuários, as chaves são armazenadas como secrets do Kubernetes no plano de controle de administrador. O servidor da API é configurado com um certificado fornecido pelo usuário e assinado pela CA org. O servidor da API usa a indicação de nome do servidor (SNI, na sigla em inglês) para determinar qual chave assinada será usada, a da CA cluster ou a da CA org.

A autenticação de cluster do GKE no VMware é processada por certificados e tokens do portador da conta de serviço. Como administrador, você se autentica no plano de controle usando o OIDC ou o certificado administrativo (usado para a criação da vinculação de papel inicial ou para fins de emergência).

A rotação de certificados é processada das maneiras a seguir:

  • Para planos de controle, nós e o servidor de API, os certificados são criados ou alternados a cada upgrade.
  • As CAs podem ser alternados raramente ou sob demanda.

Segurança de nós

O GKE em VMware implanta as cargas de trabalho em instâncias de VMware, que são anexadas aos clusters como nós. As seções a seguir mostram como usar os recursos de segurança no nível do nó disponíveis no GKE em VMware.

Ubuntu

O GKE no VMware usa uma versão otimizada do Ubuntu como o sistema operacional em que o plano de controle e os nós do Kubernetes são executados. O Ubuntu inclui um conjunto avançado de recursos de segurança modernos. O GKE em VMware implementa vários recursos de aprimoramento de segurança para clusters, incluindo:

Há guias de segurança extras disponíveis para o Ubuntu, como esta (links em inglês):

Upgrades de nós

Atualize seus nós regularmente. Às vezes, pode ser necessário fazer upgrade dos nós com mais urgência por conta de problemas de segurança no ambiente de execução do contêiner, no próprio Kubernetes ou no sistema operacional dos nós. Quando você faz o upgrade do cluster, cada software do nó é atualizado para as versões mais recentes.

Como proteger suas cargas de trabalho

O Kubernetes permite que os usuários provisionem, escalonem e atualizem rapidamente as cargas de trabalho baseadas em contêiner. Nesta seção, você verá as táticas que administradores e usuários podem usar para limitar a capacidade dos contêineres em execução de afetar outros contêineres no cluster, os hosts em que são executados e os serviços do Google Cloud ativados no projeto.

Como limitar os privilégios de processos em contêiner de pod

A limitação dos privilégios de processos em contêiner é importante para a segurança geral do cluster. O Kubernetes Engine permite que você defina opções relacionadas à segurança por meio do contexto de segurança em pods e contêineres. Com essas configurações, é possível alterar as configurações de segurança dos seus processos, como:

  • usuário e grupo de execução;
  • recursos disponíveis do Linux;
  • escalonamento de privilégios.

O sistema operacional de nós padrão do GKE no VMware, Ubuntu, aplica as políticas de segurança padrão do Docker AppArmor a todos os contêineres iniciados pelo Kubernetes. É possível ver o modelo do perfil GitHub (em inglês). Entre outras coisas, o perfil nega os seguintes recursos aos contêineres:

  • Gravar em arquivos diretamente em um diretório de ID do processo (/proc/)
  • Gravar em arquivos que não estão em /proc/
  • Gravar em arquivos em /proc/sys em vez de /proc/sys/kernel/shm*
  • Montar sistemas de arquivos

Registro de auditoria

Com a geração de registros de auditoria do Kubernetes, os administradores podem reter, consultar, processar e alertar sobre eventos que ocorrem nos ambientes do GKE no VMware. Os administradores podem usar as informações registradas para fazer análises forenses, emitir alertas em tempo real ou catalogar como e por quem uma frota de clusters do Kubernetes Engine está sendo usada.

Por padrão, o GKE em VMware registra a atividade do administrador. Se quiser, também é possível registrar eventos de acesso a dados, dependendo dos tipos de operações que você quer inspecionar.

O agente do Connect se comunica apenas com o servidor da API local em execução no local, e cada cluster precisa ter o próprio conjunto de registros de auditoria. Todas as ações que os usuários realizam a partir da IU por meio do Connect são registradas por esse cluster.

Criptografia

Se os clusters e cargas de trabalho do GKE no VMware se conectarem com segurança aos serviços do Google Cloud por meio do Cloud VPN, você poderá usar o Cloud Key Management Service (Cloud KMS) para gerenciamento de chaves. O Cloud KMS é um serviço de gerenciamento de chaves hospedado na nuvem que permite gerenciar a criptografia dos serviços. Você pode gerar, usar, alternar e destruir chaves criptográficas AES256, RSA 2048, RSA 3072, RSA 4096, EC P256 e EC P384. O Cloud KMS é integrado ao gerenciamento de identidade e acesso (IAM) e ao Cloud Audit Logging, o que permite gerenciar permissões em chaves individuais e monitorar como elas são usadas. Use o Cloud KMS para proteger secrets e outros dados confidenciais que você precisa armazenar. Se não, use uma das alternativas a seguir:

  • Secrets do Kubernetes
  • HashiCorp Vault
  • HSM de rede Thales Luna
  • Módulo de segurança de hardware do Google Cloud (HSM)

Secrets do Kubernetes

Os recursos secrets do Kubernetes armazenam nos clusters dados confidenciais, como senhas, tokens OAuth e chaves SSH. Armazenar dados confidenciais em Secrets é mais seguro do que armazená-los em ConfigMaps de texto simples ou nas especificações do pod. Com os secrets, você controla como os dados confidenciais são usados e reduz o risco de expô-los a usuários não autorizados.

HashiCorp Vault

Módulo de segurança de hardware