Informações gerais da segurança

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

Os clusters do GKE oferecem recursos para proteger as cargas de trabalho, incluindo o conteúdo da imagem de contêiner, o ambiente de execução do contêiner, a rede de cluster e o acesso ao servidor da API do cluster.

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

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 GKE no Azure criptografa os dados no etcd e nos volumes de armazenamento em repouso usando chaves gerenciadas pela plataforma Azure.

Os clusters do GKE nos Azure armazenam dados em volumes do Disco do Azure. Esses volumes são sempre criptografados em repouso usando as chaves do Azure Key Vault. Ao criar clusters e pools de nós, é possível fornecer uma chave Keyvault gerenciada pelo cliente para criptografar os volumes de disco subjacentes do cluster. Se você não especificar uma chave, o Azure usará a chave padrão gerenciada pelo Azure na região do Azure em que o cluster for executado.

Além disso, todos os clusters do GKE ativam a criptografia de secrets da camada de aplicativos para dados confidenciais, como objetos 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, é possível fornecer uma chave do Azure Key Vault no parâmetro --database-encryption-kms-key-arn. Essa chave é usada para criptografia dos dados do seu aplicativo. Se você não fornecer uma chave durante a criação do cluster, o GKE no Azure criará uma automaticamente para o cluster. Esse campo de recursos é imutável e não pode ser modificado depois que o cluster é criado.

Também é possível criar manualmente uma chave do Vault ou trazer sua própria chave (BYOK, na sigla em inglês) com um módulo de segurança de hardware (HSM, na sigla em inglês). Para mais informações, consulte Usar sua própria chave.

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 Azure Key Vault para criptografia.

  4. O Azure Key Vault usa uma KEK pré-gerada para criptografar a DEK e retornar a DEK criptografada para o plug-in Azure Key Vault do servidor da API Kubernetes.

  5. O servidor da API Kubernetes salva o secret criptografado e a DEK criptografada no etcd. O texto simples 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 Azure Key Vault.

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 Azure Key Vault 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.

Configurar criptografia com o firewall do Key Vault

Se você transmitir uma chave pública para criptografia, o principal de serviço não precisará da permissão para criptografar, mas precisará da permissão para gerenciar atribuições de papel. A maneira mais fácil de fazer isso é atribuir o papel integrado User Access Administrator do Azure ao principal de serviço.

Para proteger ainda mais o Azure Key Vault, ative o firewall do Azure Key Vault. O GKE no Azure pode usar uma chave pública para criptografia e evitar o acesso de rede ao Key Vault.

Para configurar o firewall, faça o download da chave do Key Vault com a CLI do Azure. Transmita a chave para o --config-encryption-public-key ao criar um cluster com a CLI do Google Cloud.

Você ainda precisa ativar os endpoints do serviço para o Key Vault em todas as sub-redes usadas para o cluster. Para mais informações, consulte Endpoints do serviço de rede virtual para o Azure Key Vault.

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.

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 no Azure implanta suas cargas de trabalho em pools de nós de instâncias de VM do Azure. A seção a seguir explica os recursos de segurança dos nós.

Ubuntu

Seus nós executam uma versão otimizada do SO 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:

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, no sistema operacional padrão do nó do GKE no Azure, 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 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, é possível limitar as permissões instalando o Policy Controller ou o Gatekeeper no cluster e aplicando restrições, como o NoUpdateServiceAccount da biblioteca de código aberto Gatekeeper, 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 no Azure, será preciso definir os seguintes parâmetros em 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.

Isolar cargas de trabalho em pools de nós dedicados

É possível usar os taints e as tolerâncias do Kubernetes para designar pools de nós específicos para executar tipos específicos de cargas de trabalho. Por exemplo, é possível instruir o GKE no Azure a programar 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 com taints e tolerâncias não é uma medida de segurança garantida. Use-a apenas com outras medidas de proteção que o GKE no Azure oferece.

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

A seguir