Chiffrer vos données en transit dans GKE avec des clés de chiffrement gérées par l'utilisateur

Standard

Cette page explique comment activer le chiffrement des données en transit pour les communications de pods sur les nœuds Google Kubernetes Engine (GKE) à l'aide de clés de chiffrement gérées par l'utilisateur.

Par défaut, Google chiffre toutes les données en transit entre les VM. au niveau de la carte d'interface réseau pour garantir la confidentialité des données en transit, quel que soit le service ou l'application exécutés sur la VM (y compris GKE). Cette couche de chiffrement s'applique à tous les nœuds GKE et au trafic des pods. Les clés de chiffrement sont fournies et gérées par Google.

Grâce au chiffrement transparent entre les nœuds pour GKE, Google vous offre plus de contrôle sur les clés de chiffrement utilisées pour chiffrer le trafic des pods sur les nœuds GKE. GKE effectue ce chiffrement à l'aide de WireGuard dans GKE Dataplane V2, en plus du chiffrement par défaut fourni par les cartes d'interface réseau des VM.

Fournir ce contrôle sur les clés de chiffrement directement dans GKE est utile si vous travaillez dans un secteur réglementé et que vous avez besoin d'audits de conformité et de sécurité.

Vous pouvez activer le chiffrement transparent entre les nœuds dans des environnements uniques et multiclusters. Pour en savoir plus sur cette fonctionnalité, consultez la page Fonctionnement du chiffrement transparent entre les nœuds avec GKE.

Limites

Cette fonctionnalité ne garantit pas à elle seule que Google ne puisse pas accéder aux clés de chiffrement stockées dans la mémoire du nœud GKE. Dans certains environnements ou juridictions réglementées, ou pour répondre à des exigences de conformité spécifiques, vous pouvez souhaiter chiffrer davantage ces clés et contrôler les accès. Pour ce faire, nous vous recommandons d'utiliser le chiffrement transparent entre les nœuds avec des nœuds Confidential GKE Node qui utilisent des clés de chiffrement gérées par le client (CMEK). Les nœuds Confidential GKE Node qui utilisent des CMEK chiffrent le contenu de la mémoire des nœuds à l'aide de clés que vous gérez.
Le chiffrement transparent entre les nœuds pour GKE n'est compatible qu'avec les clusters GKE Dataplane V2.
GKE Autopilot n'est pas compatible.
Le chiffrement transparent entre les nœuds pour GKE utilise WireGuard. WireGuard n'est pas conforme à la norme FIPS.
Les clés de chiffrement ne font pas l'objet d'une rotation dynamique. La rotation des clés doit être gérée manuellement en redémarrant les nœuds.
Le chiffrement transparent entre les nœuds et les nœuds Confidential GKE Node ne fonctionnent que sur Container-Optimized OS (COS) et Ubuntu, et non sur Windows.
Le chiffrement transparent entre les nœuds ne chiffre pas le trafic réseau lancé par le nœud GKE ou un pod à l'aide de hostNetwork.
Le chiffrement transparent entre les nœuds ne chiffre pas le trafic réseau envoyé à un pod exposé sur un port de nœud. Même lorsque ExternalTrafficPolicy: Cluster est configuré sur le service, le trafic transféré du premier nœud recevant le trafic du client au pod de backend n'est pas chiffré.
Le nombre maximal de nœuds compatibles avec le chiffrement transparent entre les nœuds activé pour les configurations à cluster unique ou multicluster est de 500.
Le chiffrement transparent entre les nœuds peut entraîner un surabonnement des nœuds. Prévoyez une augmentation moyenne de l'utilisation du processeur de 15 % sur les nœuds n2-standard-8 avec le système d'exploitation Ubuntu avec un débit de 2 Gbit/s.

L'augmentation de l'utilisation du processeur n'est attribuée à aucun pod, car le kube-scheduler n'en a pas connaissance. Le pod avec un trafic accru peut utiliser toutes les ressources de processeur du nœud. Cela peut empêcher les autres pods d'obtenir les ressources de processeur dont ils ont besoin, même s'ils sont correctement configurés. Cela peut poser des problèmes pour les pods qui tentent d'exécuter des charges de travail sensibles ou qui doivent pouvoir répondre rapidement aux requêtes. Pour contourner ce problème, vous pouvez maintenir une quantité importante de processeurs non programmés sur les nœuds sur lesquels le chiffrement transparent entre les nœuds est activé. Vous pouvez également programmer un pod avec une PriorityClass faible, qui reçoit une demande de processeur importante, mais n'utilise jamais ce processeur.
Le chiffrement transparent entre les nœuds entraîne une latence de 150 microsecondes sur deux nœuds de la même zone qui n'utilisent pas de nœuds Confidential GKE Node.
Lorsque vous activez le chiffrement transparent entre les nœuds, les fonctionnalités d'observabilité du trafic utilisées pour suivre le trafic sur les pods peuvent ne pas fonctionner comme prévu, car les données en transit sont chiffrées avec des clés non accessibles à l'infrastructure Google sous-jacente.
Lorsque vous activez le chiffrement transparent entre les nœuds, les adresses IP des pods ne sont pas visibles sur le VPC. Les fonctionnalités qui dépendent de l'inspection des paquets, telles que la mise en miroir de paquets et les règles de pare-feu VPC basées sur le CIDR des pods, ne sont pas compatibles avec le chiffrement transparent entre les nœuds.
Lorsque vous activez le chiffrement transparent entre les nœuds sur les clusters associés à différents sous-réseaux VPC, vous devez créer manuellement des règles de pare-feu pour autoriser les communications entre les nœuds du cluster.
Le chiffrement transparent entre les nœuds désactive certaines fonctionnalités de couche 7 de GKE Dataplane V2. Par conséquent, vous ne pouvez pas activer simultanément la règle de réseau FQDN et le chiffrement transparent entre les nœuds.
Vous ne pouvez pas activer cette fonctionnalité en même temps que la visibilité intranœud.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

Activez l'API Google Kubernetes Engine.

Activer l'API Google Kubernetes Engine

Si vous souhaitez utiliser Google Cloud CLI pour cette tâche, installez puis initialisez gcloud CLI. Si vous avez déjà installé gcloud CLI, assurez-vous de disposer de la dernière version en exécutant la commande gcloud components update.
Remarque : Pour les installations de gcloud CLI existantes, veillez à définir les propriétés compute/region et compute/zone. En définissant des emplacements par défaut, vous pouvez éviter les erreurs gcloud CLI telles que celle-ci : One of [--zone, --region] must be supplied: Please specify location.

Suivez les instructions pour activer GKE Enterprise.
Le chiffrement transparent entre les nœuds GKE n'est compatible qu'avec Google Cloud CLI version 458.0.0 et ultérieure, ainsi que les versions suivantes de GKE :
- 1.26.10-gke.1024000 ou versions ultérieures
- 1.27.7-gke.1506000 ou versions ultérieures
- 1.28.2-gke.1098000 ou versions ultérieures

Activer le chiffrement transparent entre les nœuds avec GKE

Vous pouvez activer le chiffrement transparent entre les nœuds avec GKE sur un seul cluster ou dans un environnement multicluster.

Activer le chiffrement transparent entre les nœuds sur un nouveau cluster

Pour activer le chiffrement transparent entre les nœuds sur un nouveau cluster, procédez comme suit :
```
gcloud container clusters create CLUSTER_NAME \
    --region=REGION \
    --enable-datapane-v2 \
    --in-transit-encryption inter-node-transparent
```
Remplacez les éléments suivants :
- CLUSTER_NAME par le nom de votre cluster.
- REGION par la région de calcul de votre cluster.
Remarque : Nous vous recommandons de créer des clusters avec le chiffrement entre les nœuds activé, plutôt que de les créer avec le chiffrement entre les nœuds désactivé puis de l'activer. L'activation ultérieure du chiffrement entre les nœuds peut entraîner des redémarrages du pool de nœuds.
Pour vérifier votre configuration, exécutez la commande suivante afin de vérifier l'état du chiffrement :
```
kubectl -n kube-system exec -ti anetd-XXXX -- cilium status | grep Encryption
```
Le résultat ressemble à ce qui suit :
```
Encryption: Wireguard [cilium_wg0 (Pubkey: <key>, Port: 51871, Peers: 2)]
```
Remarque : Vérifiez que le nombre de pairs est inférieur de 1 au nombre de nœuds de votre cluster. Par exemple, dans un cluster comportant 24 nœuds, le nombre de pairs doit être de 23. Si le nombre de pairs n'est pas inférieur au nombre de nœuds du cluster, redémarrez l'agent anetd sur vos nœuds.

Activer le chiffrement transparent entre les nœuds sur un cluster existant

Pour activer le chiffrement transparent entre les nœuds sur un cluster existant, procédez comme suit :
```
gcloud container clusters update CLUSTER_NAME \
  --in-transit-encryption inter-node-transparent \
  --region=REGION
```
Remplacez les éléments suivants :
- CLUSTER_NAME par le nom de votre cluster.
- REGION par la région de calcul de votre cluster.
Remarque : Nous vous recommandons d'effectuer cette opération pendant un intervalle de maintenance, car elle peut perturber le trafic vers votre pod. La mise à jour du cluster et l'installation du réseau de chiffrement entre les nœuds peuvent nécessiter plusieurs heures.
Pour vérifier que la commande Google Cloud CLI a bien été exécutée, procédez comme suit :
```
gcloud container clusters describe CLUSTER_NAME \
    --region=REGION \
    --format json | jq .status
```
Remplacez les éléments suivants :
- CLUSTER_NAME par le nom de votre cluster.
- REGION par la région de calcul de votre cluster.
Attendez que l'état indique "RUNNING" (En cours d'exécution). L'activation du chiffrement entre les nœuds dans GKE redémarre automatiquement les nœuds. Le redémarrage des nœuds et l'application des règles par les nouveaux nœuds peuvent prendre plusieurs heures.
Pour vérifier que les nœuds ont redémarré, procédez comme suit :
```
kubectl get nodes
```
Vérifiez le champ AGE de chaque nœud et continuez si le champ AGE reflète les nouveaux nœuds.
Pour vérifier votre configuration, vous pouvez exécuter la commande suivante afin de vérifier l'état du chiffrement :
```
kubectl -n kube-system exec -ti anetd-XXXX -- cilium status | grep Encryption
```
Le résultat ressemble à ce qui suit :
```
Encryption: Wireguard [cilium_wg0 (Pubkey: <key>, Port: 51871, Peers: 2)]
```
Vérifiez que le nombre de pairs est inférieur de 1 au nombre de nœuds de votre cluster. Par exemple, dans un cluster comportant 24 nœuds, le nombre de pairs doit être de 23. Si le nombre de pairs n'est pas inférieur au nombre de nœuds du cluster, redémarrez l'agent anetd sur vos nœuds.

Activer le chiffrement transparent entre les nœuds sur l'ensemble des clusters

Le chiffrement transparent entre les nœuds n'est pas compatible avec les clusters Autopilot. Si votre parc inclut des clusters Autopilot, ils ne pourront pas communiquer avec les clusters standards pour lesquels le chiffrement est activé.

Pour activer le chiffrement transparent entre les nœuds dans un environnement multicluster, procédez comme suit :

Activez le chiffrement transparent entre les nœuds sur un nouveau cluster ou dans un cluster existant.
Enregistrez votre cluster dans un parc.
Activez le chiffrement transparent entre les nœuds pour le parc :
```
gcloud container fleet dataplane-v2-encryption enable --project PROJECT_ID
```
Remplacez PROJECT_ID par l'ID du projet.
Vérifiez l'état sur tous les nœuds :
```
kubectl -n kube-system get pods -l k8s-app=cilium -o name | xargs -I {} kubectl -n kube-system exec -ti {} -- cilium status
```
Le résultat ressemble à ce qui suit :
```
...
Encryption: Wireguard [cilium_wg0 (Pubkey: <key>, Port: 51871, Peers: 5)]
...
```
Remarque : Vérifiez que le nombre de pairs est inférieur de 1 au nombre de nœuds de tous les clusters enregistrés. Par exemple, dans un cluster comportant 24 nœuds, le nombre de pairs doit être de 23. Si le nombre de pairs n'est pas inférieur au nombre de nœuds du cluster, redémarrez l'agent anetd sur vos nœuds.

Désactiver le chiffrement transparent entre les nœuds

Dans certains cas, vous pouvez désactiver le chiffrement transparent entre les nœuds dans votre cluster GKE afin d'améliorer les performances ou de résoudre les problèmes de connectivité de votre application. Avant de poursuivre cette opération, tenez compte des points suivants :

Le chiffrement transparent entre les nœuds est activé pour l'ensemble du cluster et vous ne pouvez pas le désactiver partiellement dans des ressources Kubernetes individuelles, telles que des espaces de noms ou des pods.
Effectuez cette opération pendant un intervalle de maintenance, car elle perturbera le trafic de votre pod.

Sur un seul cluster

Pour désactiver le chiffrement transparent entre les nœuds sur un seul cluster, procédez comme suit :

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

Remplacez les éléments suivants :

CLUSTER_NAME par le nom de votre cluster.
REGION : par la région de calcul de votre cluster.

Désactiver sur un cluster faisant partie d'un parc

Vous pouvez désactiver le chiffrement d'un cluster dans un parc à l'aide de l'une des deux options suivantes :

Pour supprimer complètement le cluster du parc, annulez l'enregistrement de votre cluster.
Vous pouvez également conserver le cluster dans le parc, mais désactiver le chiffrement :
```
gcloud container fleet dataplane-v2-encryption disable --project PROJECT_ID
```
Remplacez PROJECT_ID par l'ID du projet.

La désactivation du chiffrement avec cette commande entraîne la suppression des nœuds distants de la liste des pairs WireGuard sur chaque cluster. Ce processus peut prendre plusieurs minutes, en fonction du nombre de clusters et de nœuds impliqués. Pour afficher le nombre de pairs mis à jour, vous devez actualiser manuellement la liste des pairs WireGuard sur chaque cluster. Vous pouvez utiliser votre outil de gestion de clusters ou la commande suivante :
```
kubectl -n kube-system exec -ti anetd-XXXX -- cilium status | grep Encryption
```

Désactiver sur l'ensemble d'un parc de clusters

Pour désactiver le chiffrement transparent entre les nœuds dans un parc, procédez comme suit :
```
gcloud container fleet dataplane-v2-encryption disable --project PROJECT_ID
```
Remplacez PROJECT_ID par l'ID du projet.
Pour désactiver le chiffrement transparent entre les nœuds et supprimer l'API désormais inutilisée, désactivez l'API GKE Dataplane V2 au niveau du parc. Cela désactivera le contrôleur GKE Dataplane V2 exécuté dans votre parc.
```
gcloud services disable gkedataplanev2.googleapis.com \
    --project=PROJECT_ID
```
Remplacez PROJECT_ID par l'ID du projet.

Remarque : Cette API est responsable de la fonctionnalité de chiffrement transparent entre les nœuds de votre parc. Assurez-vous de vérifier que cette API n'est utilisée par aucun autre élément de votre parc avant de la désactiver afin d'éviter tout comportement inattendu.

Pour gérer efficacement les clusters portant le même nom et garantir l'activation du chiffrement multicluster, procédez comme suit :
1. Annulez l'enregistrement de l'ancien cluster dans le parc avant d'en créer un autre portant le même nom.
2. Réenregistrez le nouveau cluster lors de la recréation.
3. Si vous oubliez d'annuler l'enregistrement d'un cluster, supprimez l'ancienne appartenance et recréez le cluster avec une nouvelle appartenance.
Si vous ne suivez pas ces étapes, le chiffrement multicluster peut ne pas s'activer sur le nouveau cluster tant que l'appartenance au parc n'est pas recréée.

Fonctionnement du chiffrement transparent entre les nœuds avec GKE

Les sections suivantes décrivent le fonctionnement du chiffrement transparent entre les nœuds lorsque vous l'activez dans votre cluster :

Chiffrement du trafic réseau entre deux pods sur différents nœuds

Lorsque le chiffrement transparent entre les nœuds est activé, GKE Dataplane V2 chiffre le trafic entre les pods si ceux-ci se trouvent sur des nœuds différents, quel que soit le cluster auquel ces nœuds appartiennent. Lorsque les clusters font partie du même parc, ils appartiennent au même domaine de chiffrement.

Les clusters avec différentes configurations de chiffrement transparent entre les nœuds peuvent coexister dans le même parc. Si vous disposez d'un environnement multicluster dans lequel seuls certains clusters utilisent le chiffrement transparent entre les nœuds, les considérations suivantes s'appliquent :

La communication de pod à pod entre les nœuds d'un même cluster est chiffrée à l'aide de la paire de clés publique/privée.
La communication de pod à pod entre un nœud d'un cluster pour lequel le chiffrement transparent entre les nœuds est activé et un nœud d'un cluster pour lequel le chiffrement transparent entre les nœuds n'est pas activé échoue.

Génération et utilisation des clés de chiffrement

Lorsque la fonctionnalité est activée, chaque nœud GKE du cluster génère automatiquement une paire de clés publique/privée appelée clés de chiffrement.

La clé privée est stockée en mémoire (et non sur le disque) et ne quitte jamais le nœud. L'utilisation des nœuds GKE Confidential Node réduit davantage le risque de compromission de clés, car la mémoire du nœud est également chiffrée (avec des clés différentes).
La clé publique est partagée avec d'autres nœuds à l'aide du plan de contrôle GKE Dataplane V2. Elle est accessible à tous les nœuds du même domaine de chiffrement.

Une fois les clés échangées, chaque nœud peut établir un tunnel WireGuard avec d'autres nœuds dans le même domaine de chiffrement. Chaque tunnel est unique pour une paire de nœuds donnée.

Tenez compte des points suivants lorsque vous travaillez avec les paires de clés privées ou publiques et une clé de session :

Paire de clés privée/publique :
- La clé publique est distribuée dans le cluster et tous les nœuds du cluster peuvent y accéder.
- La paire de clés est alternée au redémarrage du nœud. GKE n'effectue pas de rotation des clés à intervalles réguliers. Pour déclencher manuellement une rotation des clés, drainez et redémarrez le nœud. Cela invalide la paire de clés d'origine et génère une nouvelle paire de clés.
Clé de session :
- Cette clé n'est pas configurable.
- Cette clé est régulièrement alternée toutes les deux minutes.
- La clé de session est exclusive aux nœuds impliqués dans le tunnel.