Descrição geral de segurança

Esta página descreve a arquitetura de segurança do GKE no Azure, 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 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 no Azure encripta os dados no etcd e nos volumes de armazenamento em repouso através de chaves geridas pela plataforma Azure.

Os clusters do GKE no Azure armazenam dados em volumes de disco do Azure. Estes volumes são sempre encriptados em repouso através de chaves do Azure Key Vault. Quando cria clusters e pools de nós, pode fornecer uma chave do Keyvault gerida pelo cliente para encriptar os volumes de disco subjacentes do cluster. Se não especificar uma chave, o Azure usa a chave gerida pelo Azure predefinida na região do Azure 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, pode fornecer uma chave do Azure Key Vault no parâmetro --database-encryption-kms-key-arn. Esta chave é usada para a encriptação dos dados da sua aplicação. Se não fornecer uma chave durante a criação do cluster, o GKE no Azure cria uma automaticamente para o cluster. Este campo de recurso é imutável e não pode ser modificado depois de o cluster ser criado.

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

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 Azure Key Vault para encriptação.

  4. O Azure Key Vault usa uma KEK pré-gerada para encriptar a DEK e devolve a DEK encriptada ao plug-in do Azure Key Vault 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 Azure Key Vault.

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

Configure a encriptação com a firewall do Key Vault

Se transmitir uma chave pública para encriptação, o principal de serviço não precisa da autorização para encriptar, mas precisa da autorização para gerir atribuições de funções. A forma mais fácil de o fazer é atribuir a função integrada do Azure User Access Administrator ao seu principal de serviço.

Para proteger ainda mais o Azure Key Vault, pode ativar a firewall do Azure Key Vault. Em seguida, o GKE no Azure pode usar uma chave pública para encriptação e evitar o acesso de rede ao cofre de chaves.

Para configurar a firewall, transfira a chave do Key Vault com a CLI do Azure. Transmite a chave ao --config-encryption-public-key quando cria um cluster com a CLI do Google Cloud.

Ainda tem de ativar os pontos finais de serviço para o Key Vault em todas as sub-redes usadas para o cluster. Para mais informações, consulte o artigo Pontos finais do serviço de rede virtual para o Azure Key Vault.

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.

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 no Azure implementa as suas cargas de trabalho em conjuntos de nós de instâncias de VM do Azure. 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 no Azure, o Ubuntu, usa as políticas de segurança do Docker AppArmor predefinidas 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 Azure, 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.

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 no Azure 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 diferentes pools de nós.

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 Azure oferece.

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

O que se segue?