Criptografe dados em trânsito no GKE com chaves de criptografia gerenciadas pelo usuário

Padrão

Nesta página, mostramos como ativar a criptografia de dados em trânsito para comunicações de pod nos nós do Google Kubernetes Engine (GKE) com chaves de criptografia gerenciadas pelo usuário.

Por padrão, o Googleque criptografa todos os dados em trânsito entre as VMs no nível do controlador de interface de rede (NIC, na sigla em inglês) para garantir a confidencialidade dos dados em trânsito, independentemente de qual serviço ou aplicativo está sendo executado na VM (incluindo o GKE). Essa camada de criptografia é aplicável a todos os nós do GKE e ao tráfego de pods. As chaves de criptografia são fornecidas e gerenciadas pelo Google.

Com a criptografia transparente entre nós para o GKE, o Google oferece mais controle sobre as chaves de criptografia usadas para criptografar o tráfego de pods nos nós do GKE. O GKE executa essa criptografia usando o WireGuard no GKE Dataplane V2, além da criptografia padrão fornecida pelas placas de rede (NICs) da VM.

Fornecer esse controle sobre as chaves de criptografia diretamente no GKE é útil se você está em um setor regulamentado e precisa de auditorias de conformidade e segurança.

É possível ativar a criptografia transparente entre nós em ambientes com um e vários clusters. Para mais informações sobre como esse recurso funciona, consulte Como funciona a criptografia transparente entre nós com o GKE.

Limitações

Esse recurso por si só não garante que o Google não possa acessar as chaves de criptografia armazenadas na memória do nó do GKE. Em alguns ambientes ou jurisdições regulamentadas ou para atender a requisitos de conformidade específicos, convém criptografar ainda mais essas chaves e controlar o acesso. Para fazer isso, recomendamos que você use a criptografia transparente entre nós com nós confidenciais do GKE que usam chaves de criptografia gerenciadas pelo cliente (CMEK). Os nós confidenciais do GKE que usam criptografia CMEK nos conteúdos de memória dos nós com as chaves que você gerencia.
A criptografia transparente entre nós para o GKE só é compatível com clusters do GKE Dataplane V2.
O Autopilot do GKE não é compatível.
A criptografia transparente entre nós para o GKE usa o WireGuard. O WireGuard não está em conformidade com o FIPS.
As chaves de criptografia não são alternadas dinamicamente. A rotação de chaves precisa ser processada manualmente reiniciando os nós.
A criptografia transparente entre nós e os Confidential GKE Nodes funciona apenas no Container-Optimized OS (COS) e no Ubuntu, não no Windows.
A criptografia transparente entre nós não criptografa o tráfego de rede iniciado pelo nó do GKE ou por um pod usando a hostNetwork.
A criptografia transparente entre nós não criptografa o tráfego de rede enviado a um pod exposto em uma porta do nó. Mesmo quando ExternalTrafficPolicy: Cluster está configurado no serviço, o tráfego encaminhado do primeiro nó que recebe tráfego do cliente para o pod de back-end não é criptografado.
O número máximo de nós compatíveis com a criptografia transparente entre nós ativada para configurações de um único cluster ou de vários clusters é 500.
A criptografia transparente entre nós pode resultar no excesso de assinaturas dos nós. Você pode esperar um aumento médio de 15% na CPU em nós n2-standard-8 com o SO Ubuntu com capacidade de processamento de 2 Gbps.

O aumento na utilização da CPU não é atribuído a nenhum pod porque o kube-scheduler não reconhece. O pod com aumento de tráfego pode usar todos os recursos da CPU no nó. Isso pode impedir que outros pods recebam os recursos de CPU necessários, mesmo que estejam configurados corretamente. Isso pode causar problemas para pods que estão tentando executar cargas de trabalho confidenciais ou que precisam responder rapidamente às solicitações. Como solução alternativa, é possível manter uma quantidade significativa de CPU sem programação em nós que tenham a criptografia transparente entre nós ativada. Como alternativa, é possível programar um pod com uma PriorityClass baixa que tenha uma solicitação de CPU grande, mas nunca use essa CPU.
A criptografia transparente entre nós gera 150 microssegundos de latência em dois nós na mesma zona que não usam os Confidential GKE Nodes.
Quando você ativa a criptografia transparente entre nós, os recursos de observabilidade de tráfego usados para rastrear o tráfego nos pods podem não funcionar como esperado porque os dados em trânsito são criptografados com chaves que não podem ser acessadas infraestrutura do Google.
Quando você ativa a criptografia transparente entre nós, os endereços IP do pod não ficam visíveis na VPC. Recursos que dependem da inspeção de pacotes, como o Espelhamento de pacotes e as regras de firewall de VPC baseadas em CIDR de pods não são compatíveis com a criptografia transparente entre nós.
Ao ativar a criptografia transparente entre nós em clusters anexados a diferentes sub-redes VPC, você precisa criar regras de firewall manualmente para permitir comunicações entre os nós do cluster.
A criptografia transparente entre nós desativa alguns recursos da camada 7 do GKE Dataplane V2. Como resultado, não é possível ativar a política de rede FQDN e a criptografia transparente entre nós ao mesmo tempo.
Não é possível ativar esse recurso ao mesmo tempo que a visibilidade entre nós.

Antes de começar

Antes de começar, verifique se você realizou as tarefas a seguir:

Ativar a API Google Kubernetes Engine.

Ativar a API Google Kubernetes Engine

Se você quiser usar a Google Cloud CLI para essa tarefa, instale e, em seguida, inicialize a CLI gcloud. Se você instalou a CLI gcloud anteriormente, instale a versão mais recente executando gcloud components update.
Observação: para instalações atuais da CLI gcloud, defina as propriedades compute/region e compute/zone. Ao definir locais padrão, é possível evitar erros na gcloud CLI, como: One of [--zone, --region] must be supplied: Please specify location.

Siga as instruções para Ativar o GKE Enterprise.
A criptografia transparente entre nós do GKE é compatível apenas com a CLI do Google Cloud versão 458.0.0 e mais recente e as seguintes versões do GKE:
- 1.26.10-gke.1024000 ou mais recente.
- 1.27.7-gke.1506000 ou mais recente.
- 1.28.2-gke.1098000 ou mais recente.

Ativar a criptografia transparente entre nós com o GKE

É possível ativar a criptografia transparente entre nós com o GKE em um único cluster ou em um ambiente de vários clusters.

Ativar a criptografia transparente entre nós em um novo cluster

Para ativar a criptografia transparente entre nós em um novo cluster:
```
gcloud container clusters create CLUSTER_NAME \
    --region=REGION
    --enable-datapane-v2 \
    --in-transit-encryption inter-node-transparent
```
Substitua:
- CLUSTER_NAME pelo nome do cluster.
- REGION pela região de computação do cluster.
Observação: recomendamos que você crie novos clusters com a criptografia entre nós ativada, em vez de criá-los com a criptografia entre nós desativada. e depois ativá-la. Ativar a criptografia entre nós mais tarde pode resultar em reinicializações do pool de nós.
Para verificar sua configuração, use o seguinte comando para verificar o status da criptografia:
```
kubectl -n kube-system exec -ti anetd-XXXX -- cilium status | grep Encryption
```
O resultado será assim:
```
Encryption: Wireguard [cilium_wg0 (Pubkey: <key>, Port: 51871, Peers: 2)]
```
Observação: verifique se o número de pares é um a menos que o número de nós no cluster. Por exemplo, em um cluster com 24 nós, o número de peering precisa ser 23. Se o número de pares não for um a menos que o número de nós no cluster, reinicie o agente anetd nos nós novamente.

Ativar a criptografia transparente entre nós em um cluster atual

Para ativar a criptografia transparente entre nós em um cluster atual:
```
gcloud container clusters update CLUSTER_NAME \
  --in-transit-encryption inter-node-transparent
  --region=REGION
```
Substitua:
- CLUSTER_NAME pelo nome do cluster.
- REGION pela região de computação do cluster.
Observação: recomendamos executar essa operação durante uma janela de manutenção, porque ela pode interromper o tráfego para o pod. A atualização do cluster e a instalação da rede de criptografia entre nós podem levar várias horas para serem concluídas.
Para verificar se o comando da CLI do Google Cloud foi concluído :
```
gcloud container clusters describe CLUSTER_NAME \
    --region=REGION
    --format json | jq .status
```
Substitua:
- CLUSTER_NAME pelo nome do cluster.
- REGION pela região de computação do cluster.
Aguarde até que o status apareça como "EM EXECUÇÃO". A ativação da criptografia entre nós no GKE reinicia os nós automaticamente. Pode levar várias horas para que a reinicialização do nó ocorra e para que os novos nós apliquem as políticas.
Para confirmar que os nós foram reiniciados:
```
kubectl get nodes
```
Verifique o campo AGE de cada nó e prossiga se o campo AGE refletir novos nós.
Para verificar sua configuração, use o comando a seguir para verificar o status da criptografia:
```
kubectl -n kube-system exec -ti anetd-XXXX -- cilium status | grep Encryption
```
O resultado será assim:
```
Encryption: Wireguard [cilium_wg0 (Pubkey: <key>, Port: 51871, Peers: 2)]
```
Verifique se o número de pares é um a menos que o número de nós no cluster. Por exemplo, em um cluster com 24 nós, o número de pares precisa ser 23. Se o número de pares não for um a menos que o número de nós no cluster, reinicie o agente anetd nos nós novamente.

Ativar a criptografia transparente entre nós nos clusters

A criptografia transparente entre nós não tem suporte em clusters do Autopilot. Se a frota incluir clusters do Autopilot, ela não poderá se comunicar com clusters padrão que têm a criptografia ativada.

Para ativar a criptografia transparente entre nós em um ambiente de vários clusters:

Ative a criptografia transparente entre nós em um novo cluster ou em um cluster atual.
Registre o cluster em uma frota.
Ative a criptografia transparente entre nós na frota:
```
gcloud container fleet dataplane-v2-encryption enable --project PROJECT_ID
```
Substitua PROJECT_ID pela ID do seu projeto.
Verifique o status em todos os nós:
```
kubectl -n kube-system get pods -l k8s-app=cilium -o name | xargs -I {} kubectl -n kube-system exec -ti {} -- cilium status
```
O resultado será assim:
```
...
Encryption: Wireguard [cilium_wg0 (Pubkey: <key>, Port: 51871, Peers: 5)]
...
```
Observação: verifique se o número de pares é um a menos que o número de nós para todos os clusters registrados. Por exemplo, em um cluster cm 24 nós, o número de peerings precisa ser 23. Se o número de pares não for um a menos que o número de nós no cluster, reinicie o agente anetd nos nós novamente.

Desativar a criptografia transparente entre nós

Em alguns casos, convém desativar a criptografia transparente entre nós no cluster do GKE para melhorar o desempenho ou solucionar problemas de conectividade do aplicativo. Antes de prosseguir com esta operação, considere o seguinte:

A criptografia transparente entre nós está ativada em todo o cluster e não pode ser desativada parcialmente em recursos individuais do Kubernetes, como namespaces ou pods.
Realize essa operação durante uma janela de manutenção, porque ela vai interromper o tráfego do pod.

Em um único cluster

Para desativar a criptografia transparente entre nós em um único cluster:

gcloud container clusters update CLUSTER_NAME \
    --region=REGION
    --in-transit-encryption none

Substitua:

CLUSTER_NAME: pelo nome do cluster.
REGION: pela região de computação do cluster.

Desativar em um cluster que faz parte de uma frota

É possível desativar a criptografia de um cluster em uma frota usando uma das duas opções a seguir:

Para remover completamente o cluster da frota, cancele o registro do cluster.
Outra opção é manter o cluster na frota, mas desativar a criptografia:
```
gcloud container fleet dataplane-v2-encryption disable --project PROJECT_ID
```
Substitua PROJECT_ID pela ID do seu projeto.

Desativar a criptografia com esse comando inicia a remoção de nós remotos da lista de peerings do Wireguard em cada cluster. Esse processo pode levar vários minutos para ser concluído, dependendo do número de clusters e nós envolvidos. Para ver a contagem atualizada de peerings, você precisará atualizar manualmente a lista de peerings do WireGuard em cada cluster. Use a ferramenta de gerenciamento de clusters ou o seguinte comando:
```
kubectl -n kube-system exec -ti anetd-XXXX -- cilium status | grep Encryption
```

Desativar para uma frota inteira de clusters

Para desativar a criptografia transparente entre nós em uma frota:
```
gcloud container fleet dataplane-v2-encryption disable --project PROJECT_ID
```
Substitua PROJECT_ID pela ID do seu projeto.
Para desativar a criptografia transparente entre nós e remover a API agora não usada, desative a API GKE Dataplane V2 no nível da frota. Isso vai desativar o controlador GKE Dataplane V2 em execução na sua frota.
```
gcloud services disable gkedataplanev2.googleapis.com \
    --project=PROJECT_ID
```
Substitua PROJECT_ID pela ID do seu projeto.

Observação: essa API é responsável pelo recurso de criptografia transparente entre nós da sua frota. Para evitar comportamentos inesperados, verifique se a API não é usada por mais nada na sua frota antes de desativá-la.

Para gerenciar clusters com o mesmo nome de maneira eficiente e garantir a ativação da criptografia de vários clusters, siga estas etapas:
1. Cancele o registro do cluster antigo da frota antes de criar um novo com o mesmo nome.
2. Registre novamente o novo cluster após a recriação.
3. Se você se esquecer de cancelar o registro de um cluster, exclua a assinatura antiga e recrie o novo cluster com uma nova assinatura.
O não cumprimento dessas etapas pode fazer com que a criptografia de vários clusters não seja ativada no novo cluster até que a associação da frota seja recriada.

Como a criptografia transparente entre nós funciona com o GKE

As seções a seguir descrevem como a criptografia transparente entre nós funciona quando você a ativa no cluster:

Criptografia do tráfego de rede entre dois pods em nós diferentes.

Com a criptografia transparente entre nós ativada, o GKE Dataplane V2 criptografa o tráfego entre pods se os pods estiverem em nós diferentes, independentemente do cluster a que esses nós pertencem. Quando os clusters fazem parte da mesma frota, eles pertencem ao mesmo domínio de criptografia.

Clusters com diferentes configurações de criptografia transparente entre nós podem coexistir na mesma frota. Se você tiver um ambiente com vários clusters em que apenas alguns deles usam criptografia transparente entre nós, as considerações a seguir serão aplicadas:

A comunicação entre pods no mesmo cluster é criptografada usando o par de chaves públicas/privadas.
A comunicação entre pods entre um nó em um cluster que tem a criptografia transparente entre nós ativada e um nó em um cluster que não tem a criptografia transparente entre nós ativada falha.

Geração e uso de chaves de criptografia

Quando o recurso está ativado, cada nó do GKE no cluster gera automaticamente um par de chaves pública/privada conhecido como chaves de criptografia.

A chave privada é armazenada na memória (não no disco) e nunca sai do nó. Usar os nós confidenciais do GKE diminui ainda mais o risco de as chaves serem comprometidas, porque a memória do nó também é criptografada (com chaves diferentes).
A chave pública é compartilhada com outros nós que usam o plano de controle do GKE Dataplane V2 e pode ser acessada por todos os nós no mesmo domínio de criptografia.

Depois que as chaves são trocadas, cada nó pode estabelecer um túnel do WireGuard com outros nós no mesmo domínio de criptografia. Cada túnel é exclusivo para um determinado par de nós.

Considere o seguinte ao lidar com os pares de chaves privada ou pública e a chave de sessão:

Par de chaves privada/pública:
- A chave pública é distribuída no cluster e todos os nós nele podem acessá-la.
- O par de chaves é girado quando o nó é reiniciado. O GKE não faz a rotação de chaves em intervalos regulares. Para acionar manualmente uma rotação de chave, esvazie e reinicie o nó. Isso invalida o par de chaves original e gera um novo.
Chave de sessão:
- Essa chave não é configurável.
- Essa chave é alternada periodicamente a cada dois minutos.
- A chave de sessão é exclusiva para os nós envolvidos no túnel.