Visão geral da segurança

Nesta página, descrevemos a arquitetura de segurança do GKE na AWS, incluindo criptografia e configuração de nós.

Os clusters do GKE oferecem vários recursos para ajudar a proteger suas 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.

Ao usar clusters do GKE, você concorda em assumir determinadas responsabilidades para seus clusters. Para mais informações, consulte Responsabilidades compartilhadas dos clusters do GKE.

Criptografia do KMS da AWS

O GKE na AWS usa chaves simétricas do serviço de gerenciamento de chaves da AWS (KMS) gerenciadas pelo cliente para criptografar:

Em ambientes de produção, recomendamos usar chaves diferentes para criptografia de configuração e volume. Para minimizar ainda mais os riscos, se uma chave for comprometida, também será possível criar chaves diferentes para cada um dos seguintes itens:

Para aumentar a segurança, é possível criar uma política de chave KMS da AWS que atribua apenas o conjunto mínimo necessário de permissões. Para mais informações, consulte Como criar chaves KMS com permissões específicas.

Criptografia de dados em repouso

A criptografia de dados em repouso é a criptografia de dados armazenados, diferente dos dados em trânsito. Por padrão, o GE no Azure criptografa dados em volumes do etcd e de armazenamento em repouso usando chaves gerenciadas da plataforma do Azure.

Os clusters do GKE na AWS armazenam dados em volumes do Elastic Block Storage (EBS) da AWS. Esses volumes EBS são sempre criptografados em repouso com chaves do AWS Key Management System (AWS KMS). Ao criar clusters e pools de nós, é possível fornecer uma chave KMS gerenciada pelo cliente (CMK, na sigla em inglês) para criptografar os volumes subjacentes do EBS. Se você não especificar uma chave, a AWS usará a chave gerenciada pela AWS padrão na região da AWS em que o cluster é executado.

Além disso, todos os clusters do GKE permitem Criptografia de secrets da camada do aplicativo para dados sensíveis, como objetos de Secret do Kubernetes, que são armazenados no etcd. Mesmo que os invasores tenham acesso ao volume subjacente em que os dados do etcd estão armazenados, esses dados são criptografados.

Ao criar um cluster, você precisa transmitir uma chave KMS da AWS para o campo --database-encryption-kms-key-arn. Essa chave é usada para criptografia de envelope de dados do app. Como esse campo de recurso é imutável e não pode ser modificado depois que o cluster é criado, sugerimos que você use um alias de chave KMS. É possível usar um alias de chave para revezar as chaves usadas para criptografia em repouso durante todo o ciclo de vida do cluster.

Como funciona a criptografia no nível do aplicativo

O Kubernetes oferece criptografia no nível do aplicativo com uma técnica conhecida como criptografia de envelope. Uma chave local, normalmente chamada de chave de criptografia de dados (DEK), é usada para criptografar um secret. A própria DEK é criptografada com uma segunda chave chamada chave de criptografia de chaves (KEK, na sigla em inglês). A KEK não é armazenada pelo Kubernetes. Quando você cria um novo secret do Kubernetes, o cluster faz o seguinte:

  1. O servidor da API Kubernetes gera uma DEK exclusiva para o secret usando um gerador de números aleatórios.

  2. O servidor da API Kubernetes criptografa o secret localmente com a DEK.

  3. O servidor da API Kubernetes envia a DEK para o AWS KMS para criptografia.

  4. O AWS KMS usa uma KEK pré-gerada para criptografar a DEK e a retorna para o plug-in AWS do servidor da API Kubernetes.

  5. O servidor da API Kubernetes salva o secret criptografado e a DEK criptografada. O texto simples da DEK não é salvo no disco.

  6. O servidor da API Kubernetes cria uma entrada de cache na memória para mapear a DEK criptografada para texto simples. Isso permite que o servidor de API descriptografe secrets acessados recentemente sem consultar o KMS da AWS.

Veja o que acontece quando um cliente solicita um secret do servidor da API Kubernetes:

  1. O servidor da API do Kubernetes recupera o secret criptografado e a DEK criptografada do etcd.

  2. O servidor da API Kubernetes verifica o cache para uma entrada de mapa existente e, se encontrado, descriptografa o secret com ele.

  3. Se não houver entrada de cache correspondente, o servidor da API enviará a DEK para o AWS KMS para descriptografia usando a KEK. A DEK descriptografada é usada para descriptografar o secret.

  4. Por fim, o servidor da API Kubernetes retorna o secret descriptografado ao cliente.

Revezamento 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 em uma chave de criptografia de chaves (KEK, na sigla em inglês). Ele pode ser acionado automaticamente como parte de uma rotação programada ou manualmente, geralmente após um incidente de segurança em que as chaves podem ter sido comprometidas. A rotação de chaves substitui apenas o campo na chave que contém os dados brutos de criptografia/criptografia.

Rotação de chaves do KMS

O AWS KMS é compatível com a rotação automática de chaves do KMS. Quando ativada, a AWS gera automaticamente novo material de chave criptográfica para sua chave uma vez por ano. Não é preciso realizar ações manuais.

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

Confiança de clusters

Toda a comunicação de clusters usa o Transport Layer Security (TLS)s Cada cluster é provisionado com as seguintes principais autoridades certificadoras raiz (CAs, na sigla em inglês) autoassinadas:

  • A CA raiz do cluster é usada para validar solicitações enviadas ao servidor da API.
  • A CA raiz do etcd é usada para validar solicitações enviadas para réplicas do etcd.

Cada cluster tem uma CA raiz exclusiva. Se a CA de um cluster for comprometida, nenhuma CA de outro cluster será afetada. Todas as CAs raiz têm um período de validade de 30 anos.

Segurança de nós

O GKE na AWS implanta as cargas de trabalho em pools de nós das instâncias do AWS EC2. A seção a seguir explica os recursos de segurança dos nós.

Ubuntu

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

Os clusters do GKE implementam vários recursos de segurança, incluindo estes:

  • Conjunto de pacotes otimizado

  • Kernel do Linux personalizado para o Google Cloud

  • contas de usuário limitadas e login raiz desativado.

Outros guias de segurança estão disponíveis para o Ubuntu, como estes:

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, mostramos a você as táticas que podem ser usadas para limitar os efeitos colaterais da execução de contêineres no cluster e nos serviços do Google Cloud.

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 do cluster. É possível definir opções relacionadas à segurança com um contexto de segurança. Essas configurações permitem alterar as definições de segurança dos seus processos, como os seguintes:

  • Usuário e grupo que executam o processo
  • recursos disponíveis do Linux;
  • Escalonamento de privilégios

O Ubuntu, sistema operacional padrão do nó do GKE na AWS, usa as políticas de segurança do AppArmor do Docker padrão para todos os contêineres. É possível ver o modelo do perfil no GitHub (em inglês). Entre outras coisas, esse perfil nega os contêineres às seguintes habilidades:

  • Gravar diretamente nos arquivos 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 que não sejam /proc/sys/kernel/shm*.
  • Montar sistemas de arquivos.

Restringir a capacidade de automodificação das cargas de trabalho

Certas cargas de trabalho do Kubernetes, principalmente as cargas de trabalho do sistema, têm permissão para se automodificar. Por exemplo, algumas cargas de trabalho escalonam automaticamente na vertical. Embora seja conveniente, isso pode permitir que um invasor que já tenha comprometido um nó escalone ainda mais no cluster. Por exemplo, um invasor pode fazer com que uma carga de trabalho do nó se automodifique para ser executada como uma conta de serviço com mais privilégios que existe no mesmo namespace.

O ideal é que as cargas de trabalho não recebam permissão para se automodificar. Quando a automodificação é necessária, limite as permissões instalando o Controlador de Políticas ou o Gatekeeper no cluster e aplicando restrições, como NoUpdateServiceAccount da biblioteca Gatekeeper de código aberto, que fornece várias políticas de segurança úteis.

Ao implantar políticas, geralmente é necessário permitir que os controladores que gerenciam o ciclo de vida do cluster ignorem as políticas. Isso é necessário para que os controladores possam fazer alterações no cluster, como a aplicação de upgrades. Por exemplo, se você implantar a política NoUpdateServiceAccount no GKE na AWS, será necessário 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 (e não o ID) do projeto que hospeda o cluster.

Usar autorização binária

Outra maneira de proteger suas cargas de trabalho é ativar a autorização binária. A autorização binária é um recurso de segurança que garante que apenas imagens de contêiner confiáveis sejam implantadas nos clusters do GKE.

Veja como funciona o processo:

  1. Os administradores criam uma política que define os requisitos para implantar uma imagem. Isso inclui especificar as entidades confiáveis e autorizadas (atestadores) que podem assinar imagens e pode incluir outros critérios que uma imagem precisa atender para ser considerada segura para implantação.

  2. Um atestador (por exemplo, um desenvolvedor 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 exclusivo de caracteres) para uma imagem. Essa assinatura atua como um selo de aprovação, que indica que a imagem foi aprovada em todas as verificações e validações necessárias.

  4. Depois, a assinatura digital é "anexada" à imagem. Em outras palavras, a assinatura é armazenada nos metadados da imagem, geralmente no registro da imagem.

  5. A chave pública é registrada no sistema de autorização binária para que o sistema possa usá-la na verificação da assinatura.

  6. Quando é feita uma solicitação para implantar um contêiner, o sistema de autorização binária recupera a assinatura digital anexada à imagem no registro.

  7. O sistema de autorização binária usa a chave pública registrada para verificar a assinatura digital anexada à imagem. Ele também verifica se a imagem atende a todos os outros critérios definidos na política. Se a assinatura digital puder ser verificada com êxito usando a chave pública e os dados da imagem e a imagem atender a todos os outros critérios definidos na política, o sistema de autorização binária permitirá que o contêiner seja implantado. Se não for possível verificar a assinatura digital usando a chave pública e os dados da imagem, ou se a imagem não atender a outros critérios definidos na política, o sistema de autorização binária negará a implantação do contêiner.

Para mais informações sobre como funciona a autorização binária, consulte Visão geral da autorização binária.

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

Isolar cargas de trabalho em pools de nós dedicados

É possível usar tolerâncias e taints do Kubernetes para designar pools de nós específicos para executar tipos específicos de cargas de trabalho. Por exemplo, é possível solicitar que o GKE na AWS programe as cargas de trabalho do usuário para longe da maioria das cargas de trabalho gerenciadas pelo sistema ou colocar cargas de trabalho com diferentes níveis de confiança em diferentes pools de nós.

O isolamento de carga de trabalho usando taints e tolerâncias não é uma medida de segurança garantida. Use isso apenas com as outras medidas de proteção que o GKE na AWS oferece.

Para saber mais, consulte Isolar cargas de trabalho em pools de nós dedicados.

A seguir