Visão geral de segurança

Esta página descreve a arquitetura de segurança do GKE no Azure, 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 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 no Azure criptografa dados em etcd e volumes de armazenamento em repouso usando chaves gerenciadas pela plataforma Azure.

Os clusters do GKE no Azure armazenam dados em volumes do Azure Disk. Esses volumes são sempre criptografados em repouso usando chaves do Azure Key Vault. Ao criar clusters e pools de nós, você pode fornecer uma Chave do Key Vault 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 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.

Você também pode criar manualmente uma chave do Key Vault ou trazer sua própria chave (BYOK) com um módulo de segurança de hardware (HSM). Para mais informações, consulte Traga sua própria chave .

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

4. O Azure Key Vault usa uma KEK pré-gerada para criptografar a DEK e retorna a DEK criptografada para o plug-in Azure Key Vault 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 Azure Key Vault.

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

Configurar criptografia com o firewall do Key Vault

Se você passar uma chave pública para criptografia, a entidade de serviço não precisará da permissão para criptografar, mas precisará da permissão para gerenciar as atribuições de função. A maneira mais fácil de fazer isso é atribuir a função interna User Access Administrator do Azure à sua entidade de serviço.

Para proteger ainda mais o seu Azure Key Vault, você pode habilitar o firewall do Azure Key Vault . O GKE no Azure pode então usar uma chave pública para criptografia e evitar o acesso da rede ao cofre de chaves.

Para configurar o firewall, baixe a chave do Key Vault com a CLI do Azure . Passe a chave para --config-encryption-public-key ao criar um cluster com a CLI do Google Cloud.

Você ainda precisa habilitar os pontos de extremidade de serviço para o Key Vault em todas as sub-redes usadas para o seu cluster. Para obter mais informações, consulte Pontos de extremidade de serviço de rede virtual para o Azure Key Vault .

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.

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 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 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:

• Conjunto de pacotes otimizado

• Google Cloud-kernel Linux personalizado

• Contas de usuários limitadas e login root desabilitado

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

• Referência CIS

• DISA STIG

• FIPS 140-2

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 GKE no nó do Azure, 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 no Azure, 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.

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 no Azure a agendar cargas de trabalho do usuário 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 no Azure.

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

O que vem a seguir

• Saiba mais sobre rotação de chaves .