Esta página foi traduzida pela API Cloud Translation.

Encripte os seus dados em trânsito no GKE com chaves de encriptação geridas pelo utilizador

Padrão

Esta página mostra como encriptar dados em trânsito para comunicações de pods em nós do Google Kubernetes Engine (GKE) através de chaves de encriptação geridas pelo utilizador. Este nível de controlo sobre as suas chaves de encriptação é útil se estiver num setor regulamentado e tiver uma necessidade empresarial de auditorias de conformidade e segurança. Nesta página, vai saber como configurar o Google Kubernetes Engine (GKE) para ambientes de cluster único e múltiplo, incluindo práticas recomendadas e limitações.

Esta página destina-se a especialistas de segurança que necessitam de um controlo detalhado das chaves de encriptação para cumprir os requisitos de conformidade e segurança. Para saber mais sobre as funções comuns e as tarefas de exemplo que referimos no conteúdo, consulte o artigo Funções e tarefas comuns do utilizador do GKE. Google Cloud

Antes de ler esta página, certifique-se de que conhece os seguintes conceitos:

Dados em trânsito.
O WireGuard, que o GKE usa para realizar a encriptação no GKE Dataplane V2, além da encriptação predefinida fornecida pelas NICs de VMs.

Por predefinição, a Google encripta todos os dados em trânsito entre as VMs ao nível do controlador da interface de rede (NIC) para garantir a confidencialidade dos dados em trânsito, independentemente do serviço ou da aplicação que esteja a ser executada na VM (incluindo o GKE). Esta camada de encriptação aplica-se a todos os nós do GKE e ao tráfego de pods. As chaves de encriptação são fornecidas e geridas pela Google.

Pode ativar a encriptação transparente entre nós em ambientes de cluster único e com vários clusters. Para mais informações sobre o funcionamento desta funcionalidade, consulte o artigo Como funciona a encriptação transparente entre nós com o GKE.

Limitações

Esta funcionalidade por si só não garante que a Google não consegue aceder às chaves de encriptação armazenadas na memória do nó do GKE. Em alguns ambientes ou jurisdições regulamentados, ou para cumprir requisitos de conformidade específicos, recomendamos que encriptem ainda mais estas chaves e controlem o acesso. Para tal, recomendamos que use a encriptação transparente entre nós com nós do GKE confidenciais.
A encriptação transparente entre nós para o GKE só é suportada em clusters do GKE Dataplane V2.
O GKE Autopilot não é suportado.
A encriptação transparente entre nós para o GKE usa o WireGuard. O WireGuard não está em conformidade com a norma FIPS.
As chaves de encriptação não são rodadas dinamicamente. A alteração da chave tem de ser processada manualmente reiniciando os nós.
A encriptação transparente entre nós, juntamente com os Confidential GKE Nodes, só funciona no SO otimizado para contentores (COS) e no Ubuntu, e não no Windows.
A encriptação transparente entre nós não encripta o tráfego de rede iniciado pelo nó do GKE ou por um pod que use o hostNetwork.
A encriptação transparente entre nós não encripta o tráfego de rede enviado para um pod exposto numa porta de nó. Mesmo quando o ExternalTrafficPolicy: Cluster está configurado no serviço, o tráfego encaminhado a partir do primeiro nó que recebe tráfego do cliente para o pod de back-end não é encriptado.
O número máximo de nós suportados com a encriptação transparente entre nós ativada para configurações de cluster único ou vários clusters é de 500.
A encriptação transparente entre nós pode resultar na subscrição excessiva dos nós. Pode esperar um aumento médio de 15% na CPU em nós n2-standard-8 com o SO Ubuntu com débito de 2 Gbps.

O aumento na utilização da CPU não é atribuído a nenhum pod porque não é conhecido pelo kube-scheduler. O pod com aumento do tráfego pode usar todos os recursos da CPU no nó. Isto pode impedir que outros pods obtenham os recursos de CPU de que precisam, mesmo que estejam configurados corretamente. Isto pode causar problemas para os pods que estão a tentar executar cargas de trabalho confidenciais ou que precisam de conseguir responder rapidamente a pedidos. Como solução alternativa, pode manter uma quantidade significativa de CPU não agendada em nós com a encriptação transparente entre nós ativada. Em alternativa, pode agendar um pod com uma PriorityClass baixa que tenha um pedido de CPU grande, mas nunca use esta CPU.
A encriptação transparente entre nós incorre em 150 microssegundos de latência em dois nós na mesma zona que não usam nós confidenciais do GKE.
Quando ativa a encriptação transparente entre nós, as funcionalidades de observabilidade do tráfego usadas para monitorizar o tráfego nos pods podem não funcionar como esperado porque os dados em trânsito são encriptados com chaves que não são acessíveis à infraestrutura Google subjacente.
Quando ativa a encriptação transparente entre nós, os endereços IP dos pods não são visíveis na VPC. As funcionalidades que dependem da inspeção de pacotes, como o espelhamento de pacotes e as regras de firewall da VPC baseadas no CIDR do pod, não são compatíveis com a encriptação transparente entre nós.
Quando ativa a encriptação transparente entre nós em clusters anexados a diferentes sub-redes da VPC, tem de criar manualmente regras de firewall para permitir as comunicações entre os nós do cluster.
A encriptação transparente entre nós desativa algumas capacidades da camada 7 do GKE Dataplane V2. Como resultado, não pode ativar a política de rede FQDN e a encriptação transparente entre nós em simultâneo.
Não pode ativar esta funcionalidade ao mesmo tempo que a visibilidade intranó.

Antes de começar

Antes de começar, certifique-se de que realizou as seguintes tarefas:

Ative a API Google Kubernetes Engine.

Ative a API Google Kubernetes Engine

Se quiser usar a CLI gcloud para esta tarefa, instale-a e, em seguida, inicialize-a. Se instalou anteriormente a CLI gcloud, execute gcloud components update para obter a versão mais recente.
Nota: para instalações existentes da CLI gcloud, certifique-se de que define a compute/region propriedade. Se usar principalmente clusters zonais, defina o compute/zone. Ao definir uma localização predefinida, pode evitar erros na CLI gcloud, como os seguintes: One of [--zone, --region] must be supplied: Please specify location. Pode ter de especificar a localização em determinados comandos se a localização do seu cluster for diferente da predefinição que definiu.

A encriptação transparente entre nós do GKE só é suportada na versão 458.0.0 e posteriores da CLI gcloud e nas seguintes versões do GKE:
- 1.26.10-gke.1024000 ou posterior
- 1.27.7-gke.1506000 ou posterior
- 1.28.2-gke.1098000 ou posterior

Ative a encriptação transparente entre nós com o GKE

Pode ativar a encriptação transparente entre nós com o GKE num único cluster ou num ambiente de vários clusters.

Ative num novo cluster

Para ativar a encriptação transparente entre nós num novo cluster:
```
gcloud container clusters create CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --enable-datapane-v2 \
    --in-transit-encryption inter-node-transparent
```
Substitua o seguinte:
- CLUSTER_NAME com o nome do seu cluster.
- CONTROL_PLANE_LOCATION: a localização do Compute Engine do plano de controlo do seu cluster. Indique uma região para clusters regionais ou uma zona para clusters zonais.
Nota: recomendamos que crie novos clusters com a encriptação entre nós ativada, em vez de os criar com a encriptação entre nós desativada e ativá-la posteriormente. A ativação da encriptação entre nós mais tarde pode resultar no reinício do node pool.
Para validar a configuração, use o seguinte comando para verificar o estado da encriptação:
```
kubectl -n kube-system exec -ti anetd-XXXX -- cilium status | grep Encryption
```
O resultado é semelhante ao seguinte:
```
Encryption: Wireguard [cilium_wg0 (Pubkey: <key>, Port: 51871, Peers: 2)]
```
Nota: verifique se o número de pares é inferior em um ao número de nós no cluster. Por exemplo, num cluster com 24 nós, o número de pares deve ser 23. Se o número de pares não for inferior em um ao número de nós no cluster, reinicie novamente o agente anetd nos nós.

Ative num cluster existente

Para ativar a encriptação transparente entre nós num cluster existente:
```
gcloud container clusters update CLUSTER_NAME \
  --in-transit-encryption inter-node-transparent \
  --location=CONTROL_PLANE_LOCATION
```
Substitua o seguinte:
- CLUSTER_NAME com o nome do seu cluster.
- CONTROL_PLANE_LOCATION: a localização do Compute Engine do plano de controlo do seu cluster. Indique uma região para clusters regionais ou uma zona para clusters zonais.
Nota: recomendamos que realize esta operação durante um período de manutenção, uma vez que pode interromper o tráfego para o seu pod. A atualização do cluster e a instalação da rede de encriptação entre nós podem demorar várias horas a concluir.
Para verificar se o comando da CLI Google Cloud foi concluído com êxito :
```
gcloud container clusters describe CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --format json | jq .status
```
Substitua o seguinte:
- CLUSTER_NAME com o nome do seu cluster.
- CONTROL_PLANE_LOCATION: a localização do Compute Engine do plano de controlo do seu cluster. Indique uma região para clusters regionais ou uma zona para clusters zonais.
Aguarde até que o estado apresente "EM EXECUÇÃO". A ativação da encriptação entre nós no GKE reinicia automaticamente os nós. O reinício do nó pode demorar várias horas e os novos nós podem demorar várias horas a aplicar as políticas.
Para confirmar que os nós foram reiniciados:
```
kubectl get nodes
```
Verifique o campo AGE de cada nó e avance se o campo AGE refletir novos nós.
Para validar a configuração, pode usar o seguinte comando para verificar o estado da encriptação:
```
kubectl -n kube-system exec -ti anetd-XXXX -- cilium status | grep Encryption
```
O resultado é semelhante ao seguinte:
```
Encryption: Wireguard [cilium_wg0 (Pubkey: <key>, Port: 51871, Peers: 2)]
```
Verifique se o número de pares é inferior em um ao número de nós no seu cluster. Por exemplo, num cluster com 24 nós, o número de pares deve ser 23. Se o número de pares não for inferior em um ao número de nós no cluster, reinicie novamente o agente anetd nos seus nós.

Ative em vários clusters

A encriptação transparente entre nós não é suportada em clusters do Autopilot. Se a sua frota incluir clusters do Autopilot, estes não vão poder comunicar com clusters Standard que tenham a encriptação ativada.

Para ativar a encriptação transparente entre nós num ambiente com vários clusters:

Ative a encriptação transparente entre nós num novo cluster ou num cluster existente.
Registe o seu cluster numa frota.
Ative a encriptação transparente entre nós para a frota:
```
gcloud container fleet dataplane-v2-encryption enable --project PROJECT_ID
```
Substitua PROJECT_ID pelo ID do seu projeto.
Validar o estado 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 é semelhante ao seguinte:
```
...
Encryption: Wireguard [cilium_wg0 (Pubkey: <key>, Port: 51871, Peers: 5)]
...
```
Nota: verifique se o número de pares é inferior em um ao número de nós de todos os clusters registados. Por exemplo, num cluster com 24 nós, o número de pares deve ser 23. Se o número de pares não for inferior em um ao número de nós no cluster, reinicie novamente o agente anetd nos seus nós.

Desative a encriptação transparente entre nós

Em alguns casos, pode querer desativar a encriptação transparente entre nós no cluster do GKE para melhorar o desempenho ou resolver problemas de conetividade da sua aplicação. Antes de continuar com esta operação, considere o seguinte:

A encriptação transparente entre nós está ativada para todo o cluster e não pode desativá-la parcialmente em recursos individuais do Kubernetes, como namespaces ou pods.
Realize esta operação durante um período de manutenção, uma vez que esta operação vai interromper o tráfego do seu pod.

Desative num único cluster

Para desativar a encriptação transparente entre nós num único cluster:

gcloud container clusters update CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --in-transit-encryption none

Substitua o seguinte:

CLUSTER_NAME: com o nome do seu cluster.
CONTROL_PLANE_LOCATION: a localização do Compute Engine do plano de controlo do seu cluster. Indique uma região para clusters regionais ou uma zona para clusters zonais.

Desative num cluster que faça parte de uma frota

Pode desativar a encriptação de um cluster numa frota através de uma das duas seguintes opções:

Para remover completamente o cluster da frota, anule o registo do seu cluster.
Em alternativa, mantenha o cluster na frota, mas desative a encriptação:
```
gcloud container fleet dataplane-v2-encryption disable --project PROJECT_ID
```
Substitua PROJECT_ID pelo ID do seu projeto.

A desativação da encriptação com este comando inicia a remoção de nós remotos da lista de pares do Wireguard em cada cluster. Este processo pode demorar até vários minutos a ser concluído, dependendo do número de clusters e nós envolvidos. Para ver a quantidade de pares atualizada, tem de atualizar manualmente a lista de pares do WireGuard em cada cluster. Pode usar a ferramenta de gestão de clusters ou o seguinte comando:
```
kubectl -n kube-system exec -ti anetd-XXXX -- cilium status | grep Encryption
```

Desative para uma frota inteira de clusters

Para desativar a encriptação transparente entre nós numa frota:
```
gcloud container fleet dataplane-v2-encryption disable --project PROJECT_ID
```
Substitua PROJECT_ID pelo ID do seu projeto.
Para desativar a encriptação transparente entre nós e remover a API agora não utilizada, desative a API GKE Dataplane V2 ao nível da frota. Esta ação desativa o controlador do plano de dados V2 do GKE em execução na sua frota.
```
gcloud services disable gkedataplanev2.googleapis.com \
    --project=PROJECT_ID
```
Substitua PROJECT_ID pelo ID do seu projeto.

Nota: esta API é responsável pela funcionalidade de encriptação transparente entre nós para a sua frota. Certifique-se de que verifica se esta API não é usada por mais nada na sua frota antes de a desativar para evitar um comportamento inesperado.

Para gerir eficientemente clusters com o mesmo nome e garantir a ativação da encriptação com vários clusters, siga estes passos:
1. Anule o registo do cluster antigo da frota antes de criar um novo com o mesmo nome.
2. Volte a registar o novo cluster após a recriação.
3. Se se esquecer de anular o registo de um cluster, elimine a subscrição antiga e volte a criar o novo cluster com uma nova subscrição.
Se não seguir estes passos, a encriptação de vários clusters pode não ser ativada no novo cluster até que a associação da frota seja recriada.

Como funciona a encriptação transparente entre nós com o GKE

As secções seguintes descrevem como funciona a encriptação transparente entre nós quando a ativa no cluster:

Encriptação do tráfego de rede entre dois pods em nós diferentes

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

Os clusters com configurações de encriptação transparente entre nós diferentes podem coexistir na mesma frota. Se tiver um ambiente com vários clusters no qual apenas alguns clusters usam a encriptação transparente entre nós, aplicam-se as seguintes considerações:

A comunicação pod a pod entre nós no mesmo cluster é encriptada usando o par de chaves pública/privada.
A comunicação pod-to-pod entre um nó num cluster com a encriptação transparente entre nós ativada e um nó num cluster sem a encriptação transparente entre nós ativada falha.

Geração e utilização de chaves de encriptação

Quando a funcionalidade está ativada, cada nó do GKE no cluster gera automaticamente um par de chaves públicas/privadas conhecido como chaves de encriptação.

A chave privada é armazenada na memória (não no disco) e nunca sai do nó. A utilização de nós confidenciais do GKE diminui ainda mais o risco de as chaves serem comprometidas, uma vez que a memória do nó também é encriptada (com chaves diferentes).
A chave pública é partilhada com outros nós através do plano de controlo do GKE Dataplane V2 e é acessível a todos os nós no mesmo domínio de encriptação.

Após a troca de chaves, cada nó pode estabelecer um túnel WireGuard com outros nós no mesmo domínio de encriptação. Cada túnel é exclusivo para um determinado par de nós.

Tenha em consideração o seguinte quando lidar com os pares de chaves públicas ou privadas 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 no cluster podem aceder à chave pública.
- O par de chaves é rodado quando o nó é reiniciado. O GKE não roda as chaves a intervalos regulares. Para acionar manualmente uma rotação de chaves, esvazie e reinicie o nó. Esta ação invalida o par de chaves original e gera um novo par de chaves.
Chave da sessão:
- Esta chave não é configurável.
- Esta chave é alterada periodicamente a cada dois minutos.
- A chave de sessão é exclusiva dos nós envolvidos no túnel.