Nesta página, descrevemos os recursos de segurança incluídos no Google Distributed Cloud (somente software) para VMware, incluindo cada camada da infraestrutura, e como configurar esses recursos de segurança para atender às suas necessidades.
Visão geral
O Google Distributed Cloud (somente software) para 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 em clusters usando o OpenID Connect (OIDC) ou um token da conta de serviço do Kubernetes pelo 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 a estratégia de autenticação e autorização do Kubernetes Engine, o Google Distributed Cloud desativa o controle de acesso baseado em atributos (ABAC, na sigla em inglês) 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. No GKE os componentes do plano de controle do Kubernetes são gerenciados e mantidos pelo Google, os administradores locais gerenciam os componentes do plano de controle no Google Distributed Cloud.
No Google Distributed Cloud, os componentes do plano de controle são executados na rede corporativa. É possível proteger o servidor da API Kubernetes usando as políticas e os firewalls da rede corporativa. Também é possível atribuir um endereço IP interno ao servidor da API e limitar o acesso ao endereço.
Toda a comunicação no Google Distributed Cloud ocorre por canais TLS, que são regidos por três autoridades de certificação (CAs, na sigla em inglês): 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 é 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 Google Distributed Cloud implanta as cargas de trabalho em instâncias do 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.
Ubuntu
O Google Distributed Cloud 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 Google Distributed Cloud implementa vários recursos de aprimoramento de segurança para clusters, incluindo:
- As imagens são pré-configuradas para atender aos padrões PCI DSS, NIST Baseline High e DoD Cloud Computing SRG Impact Level 2.
- Conjunto de pacotes otimizado.
- Kernel Linux personalizado para o Google Cloud.
- Atualizações automáticas de segurança do SO opcionais.
- Contas de usuário limitadas e login raiz desativado
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 padrão do nó, Ubuntu, aplica as políticas de segurança do Docker AppArmor padrão a todos os contêineres iniciados pelo Kubernetes. É possível ver o modelo do perfil GitHub. Entre outras coisas, o perfil nega os seguintes recursos aos contêineres:
- Gravar em arquivos diretamente em um diretório de ID de 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 Google Distributed Cloud. 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 Google Distributed Cloud registra a atividade do administrador. Se quiser, também é possível registrar eventos de acesso aos 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 as cargas de trabalho se conectarem com segurança aos serviços do Google Cloud pelo Cloud VPN, use o Cloud Key Management Service (Cloud KMS) para o 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 sensíveis são usados e reduz o risco de expô-los a usuários não autorizados.