Segurança

Esta página descreve as funcionalidades de segurança incluídas no Google Distributed Cloud (apenas software) para VMware, incluindo cada camada da respetiva infraestrutura, e como pode configurar estas funcionalidades de segurança de acordo com as suas necessidades.

Vista geral

O Google Distributed Cloud (apenas software) para VMware oferece várias funcionalidades para ajudar a proteger as suas cargas de trabalho, incluindo o conteúdo da sua imagem de contentor, o tempo de execução do contentor, a rede do cluster e o acesso ao servidor da API do cluster.

É melhor adotar uma abordagem em camadas para proteger os seus clusters e cargas de trabalho. Pode aplicar o princípio do menor privilégio ao nível de acesso que concede aos seus utilizadores e cargas de trabalho. Pode ter de fazer concessões para permitir o nível certo de flexibilidade e segurança.

Autenticação e autorização

Autentica-se nos seus clusters através do OpenID Connect (OIDC) ou de um token de conta de serviço do Kubernetes através da Cloud Console.

Para configurar um acesso mais detalhado aos recursos do Kubernetes ao nível do cluster ou nos espaços de nomes do Kubernetes, usa o controlo de acesso baseado em funções (CABF) do Kubernetes. O RBAC permite-lhe criar políticas detalhadas que definem as operações e os recursos aos quais quer permitir que os utilizadores e as contas de serviço acedam. Com o RBAC, pode controlar o acesso para qualquer identidade validada fornecida.

Para simplificar e otimizar ainda mais a sua estratégia de autenticação e autorização para o Kubernetes Engine, o Google Distributed Cloud desativa o controlo de acesso baseado em atributos (ABAC) antigo.

Segurança do plano de controlo

Os componentes do plano de controlo incluem o servidor da API Kubernetes, o programador, os controladores e a base de dados etcd, onde a sua configuração do Kubernetes é mantida. Por outro lado, no GKE, os componentes do plano de controlo do Kubernetes são geridos e mantidos pela Google, enquanto os administradores locais gerem os componentes do plano de controlo no Google Distributed Cloud.

No Google Distributed Cloud, os componentes do plano de controlo são executados na sua rede corporativa. Pode proteger o servidor da API Kubernetes através das políticas de rede e firewalls corporativos existentes. Também pode atribuir um endereço IP interno ao servidor da API e limitar o acesso ao endereço.

Todas as comunicações no Google Distributed Cloud são através de canais TLS, que são regidos por três autoridades de certificação (ACs): etcd, cluster e org:

  • A AC etcd protege a comunicação do servidor da API para as réplicas etcd e também o tráfego entre as réplicas etcd. Esta AC é autoassinada.
  • A AC do cluster protege a comunicação entre o servidor da API e todos os clientes da API Kubernetes internos (kubelets, controladores e programadores). Esta AC é autossinada.
  • A AC da organização é uma AC externa usada para publicar a API Kubernetes para utilizadores externos. Gere esta AC.

Para os planos de controlo de administração, as chaves são armazenadas no nó do plano de controlo. Para clusters de utilizadores, as chaves são armazenadas como segredos do Kubernetes no plano de controlo do administrador. O servidor da API está configurado com um certificado fornecido pelo utilizador assinado pela CA da organização. O servidor da API usa a indicação do nome do servidor (SNI) para determinar se deve usar a chave assinada pela AC do cluster ou a chave assinada pela AC da organização.

A autenticação de clusters é processada por certificados e tokens de portador da conta de serviço. Enquanto administrador, autentica-se no plano de controlo através do OIDC ou com o certificado administrativo (que usa para a criação da associação de funções inicial ou para fins de emergência).

A rotação de certificados é processada das seguintes formas:

  • Para o servidor da API, os painéis de controlo e os nós, os certificados são criados ou rodados em cada atualização.
  • As ACs podem ser rodadas raramente ou a pedido.

Segurança do nó

O Google Distributed Cloud implementa as suas cargas de trabalho em instâncias do VMware, que são anexadas aos seus clusters como nós. As secções seguintes mostram como usar as funcionalidades de segurança ao nível do nó disponíveis.

Ubuntu

O Google Distributed Cloud usa uma versão otimizada do Ubuntu como o sistema operativo no qual executar o plano de controlo e os nós do Kubernetes. O Ubuntu inclui um conjunto abrangente de funcionalidades de segurança modernas e o Google Distributed Cloud implementa várias funcionalidades de melhoria da segurança para clusters, incluindo:

Estão disponíveis guias de segurança adicionais para o Ubuntu, como:

Atualizações de nós

Deve atualizar os seus nós regularmente. Periodicamente, os problemas de segurança no tempo de execução do contentor, no próprio Kubernetes ou no sistema operativo do nó podem exigir que atualize os nós com maior urgência. Quando atualiza o cluster, o software de cada nó é atualizado para as versões mais recentes.

Proteger as suas cargas de trabalho

O Kubernetes permite que os utilizadores aprovisionem, dimensionem e atualizem rapidamente cargas de trabalho baseadas em contentores. Esta secção descreve táticas que os administradores e os utilizadores podem usar para limitar a capacidade dos contentores em execução de afetar outros contentores no cluster, os anfitriões nos quais são executados e os Google Cloud serviços ativados no respetivo projeto.

Limitar os privilégios do processo do contentor do pod

Limitar os privilégios dos processos em contentores é importante para a segurança geral do cluster. O Kubernetes Engine permite-lhe definir opções relacionadas com a segurança através do contexto de segurança em pods e contentores. Estas definições permitem-lhe alterar as definições de segurança dos seus processos, como:

  • Utilizador e grupo para executar como.
  • Capacidades do Linux disponíveis.
  • Escalamento de privilégios.

O sistema operativo do nó predefinido, o Ubuntu, aplica as políticas de segurança do Docker AppArmor predefinidas a todos os contentores iniciados pelo Kubernetes. Pode ver o modelo do perfil no GitHub. Entre outras coisas, o perfil nega as seguintes capacidades aos contentores:

  • Escrever em ficheiros diretamente num diretório de ID do processo (/proc/).
  • Escrever em ficheiros que não estão em /proc/.
  • Escrever em ficheiros em /proc/sys que não sejam /proc/sys/kernel/shm*.
  • Montar sistemas de ficheiros.

Registo de auditoria

O registo de auditoria do Kubernetes oferece aos administradores uma forma de reter, consultar, processar e enviar alertas sobre eventos que ocorrem nos seus ambientes do Google Distributed Cloud. Os administradores podem usar as informações registadas para fazer análises forenses, alertas em tempo real ou para catalogar como uma frota de clusters do Kubernetes Engine está a ser usada e por quem.

Por predefinição, o Google Distributed Cloud regista a atividade do administrador. Opcionalmente, também pode registar eventos de acesso a dados, consoante os tipos de operações que tem interesse em inspecionar.

O agente Connect comunica apenas com o servidor da API local em execução no local, e cada cluster deve ter o seu próprio conjunto de registos de auditoria. Todas as ações que os utilizadores realizam a partir da IU através do Connect são registadas por esse cluster.

Encriptação

Se os seus clusters e cargas de trabalho se ligarem em segurança aos Google Cloud serviços através do Cloud VPN, pode usar o Cloud Key Management Service (Cloud KMS) para a gestão de chaves. O Cloud KMS é um serviço de gestão de chaves alojado na nuvem que lhe permite gerir chaves criptográficas para os seus serviços. Pode gerar, usar, rodar e destruir chaves criptográficas AES256, RSA 2048, RSA 3072, RSA 4096, EC P256 e EC P384. O Cloud KMS está integrado com a gestão de identidade e de acesso (IAM) e o Cloud Audit Logging para que possa gerir as autorizações de acesso a chaves individuais e monitorizar a forma como estas são usadas. Use o Cloud KMS para proteger segredos e outros dados confidenciais que precisa de armazenar. Caso contrário, pode optar por usar uma das seguintes alternativas:

  • Segredos do Kubernetes
  • Hashicorp Vault
  • Thales Luna network HSM
  • Google Cloud Módulo de segurança de hardware (HSM)

Segredos do Kubernetes

Os recursos Secrets do Kubernetes armazenam dados confidenciais, como palavras-passe, tokens OAuth e chaves SSH, nos seus clusters. O armazenamento de dados confidenciais em Secrets é mais seguro do que o armazenamento em texto simples em ConfigMaps ou em especificações de pods. A utilização de segredos dá-lhe controlo sobre a forma como os dados confidenciais são utilizados e reduz o risco de expor os dados a utilizadores não autorizados.