Descrição geral de segurança

Esta página descreve a arquitetura de segurança do GKE on AWS, incluindo a encriptação e a configuração dos nós.

Os clusters do GKE oferecem funcionalidades que ajudam a proteger as suas cargas de trabalho, incluindo o conteúdo da imagem do contentor, o tempo de execução do contentor, a rede do cluster e o acesso ao servidor da API do cluster.

Quando usa clusters do GKE, aceita assumir determinadas responsabilidades pelos seus clusters. Para mais informações, consulte o artigo Responsabilidades partilhadas dos clusters do GKE.

Encriptação do AWS KMS

O GKE no AWS usa chaves simétricas do AWS Key Management Service (KMS) geridas pelo cliente para encriptar:

Para ambientes de produção, recomendamos a utilização de chaves diferentes para a configuração e a encriptação de volumes. Para minimizar ainda mais os riscos se uma chave for comprometida, também pode criar chaves diferentes para cada um dos seguintes:

Para segurança adicional, pode criar uma política de chaves do AWS KMS que atribua apenas o conjunto de autorizações mínimo necessário. Para mais informações, consulte o artigo Criar chaves do KMS com autorizações específicas.

Encriptação de dados inativos

A encriptação de dados inativos é a encriptação de dados armazenados, ao contrário dos dados em trânsito. Por predefinição, o GKE on AWS encripta os dados no etcd e nos volumes de armazenamento em repouso com chaves geridas pela plataforma AWS.

Os clusters do GKE on AWS armazenam dados em volumes do AWS Elastic Block Storage (EBS). Estes volumes do EBS são sempre encriptados em repouso com chaves do AWS Key Management System (AWS KMS). Quando cria clusters e pools de nós, pode fornecer uma chave do KMS gerida pelo cliente (CMK) para encriptar os volumes EBS subjacentes. Se não especificar uma chave, a AWS usa a chave gerida pela AWS predefinida na região da AWS onde o cluster é executado.

Além disso, todos os clusters do GKE ativam a encriptação de segredos da camada de aplicação para dados confidenciais, como objetos secret do Kubernetes, que são armazenados no etcd. Mesmo que os atacantes obtenham acesso ao volume subjacente onde os dados etcd estão armazenados, estes dados estão encriptados.

Quando cria um cluster, tem de transmitir uma chave do AWS KMS ao campo --database-encryption-kms-key-arn. Esta chave é usada para a encriptação em envelope de dados da aplicação. Uma vez que este campo de recurso é imutável e não pode ser modificado depois de o cluster ser criado, sugerimos que use um alias da chave do KMS. Pode usar aliases de chaves para rodar as chaves usadas para a encriptação em repouso durante todo o ciclo de vida do cluster.

Como funciona a encriptação ao nível da aplicação

O Kubernetes oferece encriptação ao nível da aplicação com uma técnica conhecida como encriptação de envelope. Uma chave local, normalmente denominada chave de encriptação de dados (DEK), é usada para encriptar um segredo. A DEK é, em seguida, encriptada com uma segunda chave denominada chave de encriptação de chaves (KEK). O KEK não é armazenado pelo Kubernetes. Quando cria um novo segredo do Kubernetes, o cluster faz o seguinte:

  1. O servidor da API Kubernetes gera uma DEK exclusiva para o segredo através de um gerador de números aleatórios.

  2. O servidor da API Kubernetes encripta o segredo localmente com a DEK.

  3. O servidor da API Kubernetes envia a DEK para o AWS KMS para encriptação.

  4. O AWS KMS usa uma KEK pré-gerada para encriptar a DEK e devolve a DEK encriptada ao plug-in do AWS KMS do servidor da API Kubernetes.

  5. O servidor da API Kubernetes guarda o secret encriptado e a DEK encriptada no etcd. A DEK de texto simples não é guardada no disco.

  6. O servidor da API Kubernetes cria uma entrada de cache na memória para mapear a DEK encriptada para a DEK de texto simples. Isto permite que o servidor da API descifre os segredos acedidos recentemente sem consultar o AWS KMS.

Quando um cliente pede um segredo ao servidor da API Kubernetes, acontece o seguinte:

  1. O servidor da API Kubernetes obtém o secret encriptado e a DEK encriptada do etcd.

  2. O servidor da API Kubernetes verifica a existência de uma entrada de mapa na cache e, se a encontrar, desencripta o segredo com a mesma.

  3. Se não existir nenhuma entrada de cache correspondente, o servidor da API envia a DEK para o AWS KMS para desencriptação através da KEK. Em seguida, a DEK desencriptada é usada para desencriptar o segredo.

  4. Por fim, o servidor da API Kubernetes devolve o secret desencriptado ao cliente.

Rotação de chaves

Ao contrário da rotação de certificados, a rotação de chaves é o ato de alterar o material criptográfico subjacente contido numa chave de encriptação de chaves (KEK). Pode ser acionada automaticamente como parte de uma rotação agendada ou manualmente, normalmente após um incidente de segurança em que as chaves possam ter sido comprometidas. A rotação de chaves substitui apenas o campo único na chave que contém os dados da chave de encriptação/desencriptação não processados.

Rotação de chaves do KMS

O AWS KMS suporta a rotação automática de chaves do KMS. Quando ativada, a AWS gera automaticamente novo material de chaves criptográficas para a sua chave uma vez por ano. Não são necessárias ações manuais.

Para mais informações, consulte o artigo Rotação de chaves.

Confiança no cluster

Todas as comunicações de cluster usam o Transport Layer Security (TLS). Cada cluster é aprovisionado com as seguintes autoridades de certificação (CAs) de raiz autoassinadas principais:

  • A AC raiz do cluster é usada para validar os pedidos enviados para o servidor da API.
  • A CA raiz do etcd é usada para validar os pedidos enviados para réplicas do etcd.

Cada cluster tem uma AC raiz exclusiva. Se a AC de um cluster for comprometida, a AC de nenhum outro cluster é afetada. Todas as ACs de raiz têm um período de validade de 30 anos.

Segurança do nó

O GKE on AWS implementa as suas cargas de trabalho em conjuntos de nós de instâncias do AWS EC2. A secção seguinte explica as funcionalidades de segurança dos nós.

Ubuntu

Os seus nós executam uma versão otimizada do SO Ubuntu para executar o painel de controlo e os nós do Kubernetes. Para mais informações, consulte as funcionalidades de segurança na documentação do Ubuntu.

Os clusters do GKE implementam várias funcionalidades de segurança, incluindo as seguintes:

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

Proteja 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 as táticas que pode usar para limitar os efeitos secundários da execução de contentores no cluster e nos serviços. Google Cloud

Limite os privilégios do processo do contentor do pod

Limitar os privilégios dos processos contentorizados é importante para a segurança do seu cluster. Pode definir opções relacionadas com a segurança com um contexto de segurança. Estas definições permitem-lhe alterar as definições de segurança dos seus processos, como as seguintes:

  • Utilizador e grupo que executam o processo
  • Capacidades do Linux disponíveis
  • Escalamento de privilégios

O sistema operativo de nó predefinido do GKE on AWS, o Ubuntu, usa as políticas de segurança do AppArmor do Docker para todos os contentores. Pode ver o modelo do perfil no GitHub. Entre outras coisas, este perfil nega aos contentores as seguintes capacidades:

  • 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 seja /proc/sys/kernel/shm*
  • Montagem de sistemas de ficheiros

Restrinja a capacidade de as cargas de trabalho se automodificarem

Determinadas cargas de trabalho do Kubernetes, especialmente cargas de trabalho do sistema, têm autorização para se automodificarem. Por exemplo, algumas cargas de trabalho são dimensionadas automaticamente na vertical. Embora seja conveniente, isto pode permitir que um atacante que já comprometeu um nó avance ainda mais no cluster. Por exemplo, um atacante pode ter uma carga de trabalho no próprio nó que se altera para ser executada como uma conta de serviço mais privilegiada que existe no mesmo espaço de nomes.

Idealmente, as cargas de trabalho não devem ter autorização para se modificarem a si próprias. Quando a automodificação é necessária, pode limitar as autorizações instalando o Policy Controller ou o Gatekeeper no seu cluster e aplicando restrições, como NoUpdateServiceAccount da biblioteca Gatekeeper de código aberto, que fornece várias políticas de segurança úteis.

Quando implementa políticas, normalmente, é necessário permitir que os controladores que gerem o ciclo de vida do cluster ignorem as políticas. Isto é necessário para que os controladores possam fazer alterações ao cluster, como aplicar atualizações do cluster. Por exemplo, se implementar a política NoUpdateServiceAccount no GKE no AWS, tem de definir os seguintes parâmetros no Constraint:

parameters:
  allowedGroups: []
  allowedUsers:
  - service-PROJECT_NUMBER@gcp-sa-gkemulticloud.iam.gserviceaccount.com

Substitua PROJECT_NUMBER pelo número (não o ID) do projeto que aloja o cluster.

Use a Autorização binária

Outra forma de proteger as suas cargas de trabalho é ativar a autorização binária. A autorização binária é uma funcionalidade de segurança que garante que apenas as imagens de contentores fidedignas são implementadas em clusters do GKE.

Veja como funciona o processo:

  1. Os administradores criam uma política que define os requisitos para implementar uma imagem. Isto inclui especificar as entidades fidedignas e autorizadas (atestadores) que podem assinar imagens e pode incluir outros critérios que uma imagem tem de cumprir para ser considerada segura para implementação.

  2. Um atestador (por exemplo, um programador ou um sistema automatizado) usa um algoritmo criptográfico para gerar um par de chaves (chaves privadas e públicas).

  3. A chave privada, que é mantida em segredo, é usada para gerar uma assinatura digital (ou seja, um conjunto único de carateres) para uma imagem. Esta assinatura funciona como um selo de aprovação. É um sinal de que a imagem passou em todas as verificações e validações necessárias.

  4. A assinatura digital é, em seguida, "anexada" à imagem. Por outras palavras, a assinatura é armazenada nos metadados da imagem, normalmente no registo de imagens.

  5. A chave pública é, em seguida, registada no sistema de autorização binária para que o sistema possa usar a chave pública para a validação de assinaturas.

  6. Quando é feito um pedido para implementar um contentor, o sistema de autorização binária obtém a assinatura digital anexada à imagem no registo.

  7. O sistema de autorização binária usa a chave pública registada para validar a assinatura digital anexada à imagem. Também verifica se a imagem cumpre todos os outros critérios definidos na política. Se a assinatura digital puder ser validada com êxito através da chave pública e dos dados da imagem, e a imagem cumprir todos os outros critérios definidos na política, o sistema de autorização binária permite a implementação do contentor. Se não for possível validar com êxito a assinatura digital através da chave pública e dos dados da imagem, ou se a imagem não cumprir outros critérios definidos na política, o sistema de autorização binária nega a implementação do contentor.

Para mais informações sobre o funcionamento da autorização binária, consulte a vista geral da autorização binária.

Para ativar a autorização binária num cluster existente ou ao criar um cluster, consulte o artigo Como ativar a autorização binária.

Isole cargas de trabalho em node pools dedicados

Pode usar taints e tolerâncias do Kubernetes para designar node pools específicos para executar tipos específicos de cargas de trabalho. Por exemplo, pode indicar ao GKE on AWS para agendar cargas de trabalho do utilizador longe da maioria das cargas de trabalho geridas pelo sistema ou colocar cargas de trabalho com diferentes níveis de confiança em pools de nós diferentes.

O isolamento da carga de trabalho através de taints e tolerâncias não é uma medida de segurança garantida. Use esta opção apenas juntamente com as outras medidas de reforço que o GKE no AWS oferece.

Para saber mais, consulte o artigo Isole cargas de trabalho em node pools dedicados.

O que se segue?