Visão geral da segurança

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

Os clusters do GKE oferecem recursos para ajudar a proteger suas cargas de trabalho, incluindo o conteúdo da imagem do contêiner, o tempo 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 pelos seus clusters. Para mais informações, consulte Responsabilidades compartilhadas dos clusters do GKE .

Criptografia AWS KMS

O GKE na AWS usa chaves simétricas do AWS Key Management Service (KMS) gerenciadas pelo cliente para criptografar:

Para ambientes de produção, recomendamos o uso de chaves diferentes para configuração e criptografia de volume. Para minimizar ainda mais os riscos caso uma chave seja comprometida, você também pode criar chaves diferentes para cada um dos seguintes:

Para segurança adicional, você pode criar uma política de chaves do AWS KMS que atribui apenas o conjunto mínimo necessário de permissões. Para obter mais informações, consulte Criando chaves do KMS com permissões específicas .

Criptografia de dados em repouso

A criptografia de dados em repouso é a criptografia de dados armazenados, diferentemente dos dados em trânsito. Por padrão, o GKE na AWS criptografa dados em etcd e volumes de armazenamento em repouso usando chaves gerenciadas pela plataforma AWS.

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

Além disso, todos os clusters do GKE habilitam a Criptografia de Segredos da Camada de Aplicativo para dados confidenciais, como objetos Secret do Kubernetes, armazenados no etcd . Mesmo que invasores obtenham acesso ao volume subjacente onde os dados do etcd estão armazenados, esses dados serão criptografados.

Ao criar um cluster, você deve passar uma chave do AWS KMS para o campo --database-encryption-kms-key-arn . Essa chave é usada para criptografia de envelope dos dados do aplicativo. Como esse campo de recurso é imutável e não pode ser modificado após a criação do cluster, sugerimos que você use um alias de chave do KMS . Você pode usar um alias de chave para rotacionar as chaves usadas para criptografia em repouso ao longo do ciclo de vida do cluster.

Como funciona a criptografia em nível de aplicativo

O Kubernetes oferece criptografia em nível de aplicativo com uma técnica conhecida como criptografia de envelope . Uma chave local, comumente chamada de chave de criptografia de dados (DEK) , é usada para criptografar um segredo. A DEK em si é então criptografada com uma segunda chave, chamada de chave de criptografia de chaves (KEK) . A KEK não é armazenada pelo Kubernetes. Ao criar um novo segredo do Kubernetes, seu cluster faz o seguinte:

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

  2. O servidor da API do Kubernetes criptografa o segredo localmente com o DEK.

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

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

  5. O servidor da API do Kubernetes salva o segredo criptografado e a DEK criptografada no etcd. A DEK em texto simples não é salva no disco.

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

Quando um cliente solicita um segredo do servidor da API do Kubernetes, veja o que acontece:

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

  2. O servidor da API do Kubernetes verifica o cache em busca de uma entrada de mapa existente e, se encontrada, descriptografa o segredo com ela.

  3. Se não houver uma entrada de cache correspondente, o servidor de API envia a DEK para o AWS KMS para descriptografia usando a KEK. A DEK descriptografada é então usada para descriptografar o Segredo.

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

Rotação de Chaves

Em contraste com a rotação de certificados, a rotação de chaves é o ato de alterar o material criptográfico subjacente contido em uma chave de criptografia (KEK) . Ela pode ser acionada 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 único campo na chave que contém os dados brutos da chave de criptografia/descriptografia.

Rotação de chaves KMS

O AWS KMS oferece suporte à rotação automática de chaves KMS . Quando habilitado, a AWS gera automaticamente um novo material de chave criptográfica para a sua chave uma vez por ano. Nenhuma ação manual é necessária.

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

Fundo de cluster

Toda a comunicação do cluster utiliza o protocolo TLS (Transport Layer Security). Cada cluster é provisionado com as seguintes principais autoridades de certificação raiz (CAs) autoassinadas:

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

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

Segurança do nó

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

Ubuntu

Seus nós executam uma versão otimizada do sistema operacional Ubuntu para executar o plano de controle e os nós 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 o seguinte:

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

Proteja suas cargas de trabalho

O Kubernetes permite que os usuários provisionem, escalem e atualizem rapidamente cargas de trabalho baseadas em contêineres. Esta seção descreve táticas que você pode usar para limitar os efeitos colaterais da execução de contêineres no cluster e Google Cloud serviços.

Limitar privilégios de processo do contêiner Pod

Limitar os privilégios dos processos em contêineres é importante para a segurança do seu cluster. Você pode definir opções relacionadas à segurança com um contexto de segurança . Essas configurações permitem alterar as configurações de segurança dos seus processos, como as seguintes:

  • Usuário e grupo executando o processo
  • Recursos Linux disponíveis
  • Escalonamento de privilégios

O sistema operacional padrão do nó GKE on AWS, Ubuntu, usa as políticas de segurança padrão do Docker AppArmor para todos os contêineres. Você pode visualizar o modelo do perfil no GitHub . Entre outras coisas, este perfil nega aos contêineres as seguintes capacidades:

  • Escrevendo em arquivos diretamente em um diretório de ID de processo ( /proc/ )
  • Escrevendo em arquivos que não estão em /proc/
  • Escrevendo em arquivos em /proc/sys diferentes de /proc/sys/kernel/shm*
  • Montagem de sistemas de arquivos

Restringir a capacidade das cargas de trabalho de se automodificarem

Certas cargas de trabalho do Kubernetes, especialmente as de sistema, têm permissão para se automodificar. Por exemplo, algumas cargas de trabalho se autoescalam verticalmente. Embora conveniente, isso pode permitir que um invasor que já tenha comprometido um nó escale ainda mais no cluster. Por exemplo, um invasor pode fazer com que uma carga de trabalho no nó seja alterada para ser executada como uma conta de serviço mais privilegiada que exista no mesmo namespace.

O ideal é que as cargas de trabalho não tenham permissão para se automodificarem. Quando a automodificação for necessária, você pode limitar as permissõ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 diversas 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 as ignorem. Isso é necessário para que os controladores possam fazer alterações no cluster, como aplicar atualizações de cluster. Por exemplo, se você implantar a política NoUpdateServiceAccount no GKE na AWS, deverá definir os seguintes parâmetros na Constraint :

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

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

Usar autorização binária

Outra maneira de proteger suas cargas de trabalho é habilitar 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 em clusters do GKE.

Veja como o processo funciona:

  1. Os administradores criam uma política que define os requisitos para a implantação de uma imagem. Isso inclui a especificação das entidades confiáveis ​​e autorizadas (atestados) que podem assinar imagens e pode incluir outros critérios que uma imagem deve 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 privada e pública).

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

  4. A assinatura digital é então "anexada" à imagem. Em outras palavras, a assinatura é armazenada nos metadados da imagem, geralmente no registro de imagens.

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

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

  7. O sistema de Autorização Binária utiliza 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 sucesso 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 permite a implantação do contêiner. Se a assinatura digital não puder ser verificada com sucesso 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 nega a implantação do contêiner.

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

Para habilitar a Autorização Binária em um cluster existente ou ao criar um cluster, consulte Como habilitar a Autorização Binária .

Isole cargas de trabalho em pools de nós dedicados

Você pode usar contaminações e tolerâncias do Kubernetes para designar pools de nós específicos para executar tipos específicos de cargas de trabalho. Por exemplo, você pode instruir o GKE na AWS a agendar cargas de trabalho de usuários 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 da carga de trabalho usando contaminações e tolerâncias não é uma medida de segurança garantida. Use isso apenas em conjunto com as outras medidas de proteção oferecidas pelo GKE na AWS.

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

O que vem a seguir