Partager via

Chiffrement en transit avec WireGuard (préversion publique)

Étant donné que les organisations s’appuient de plus en plus sur Azure Kubernetes Service (AKS) pour exécuter des charges de travail conteneurisées, la sécurité du trafic réseau entre les applications et les services devient essentielle en particulier dans les environnements réglementés ou sensibles à la sécurité. Le chiffrement en transit avec WireGuard protège les données à mesure qu’elles se déplacent entre les pods et les nœuds, ce qui atténue les risques d’interception ou de falsification. WireGuard est connu pour sa simplicité et son chiffrement robuste, offre une solution puissante pour sécuriser la communication au sein des clusters AKS.

Le chiffrement WireGuard pour AKS fait partie de l’ensemble de fonctionnalités Advanced Container Networking Services (ACNS), et son implémentation est basée sur Cilium.

Important

Les fonctionnalités d’évaluation AKS sont disponibles en libre-service et font l’objet d’un abonnement. Les versions d'essai sont fournies « en l’état » et « selon disponibilité », et elles sont exclues des contrats de niveau de service et de la garantie limitée. Les versions préliminaires AKS sont, dans la mesure du possible, partiellement couvertes par le service clientèle. Par conséquent, ces fonctionnalités ne sont pas destinées à une utilisation en production. Pour plus d’informations, consultez les articles de support suivants :

Étendue de chiffrement WireGuard

Le chiffrement en transit WireGuard dans AKS est conçu pour sécuriser des flux de trafic spécifiques au sein de votre cluster Kubernetes. Cette section décrit quels types de trafic sont chiffrés et qui ne sont actuellement pas pris en charge via Advanced Container Networking Services(ACNS).

Flux de trafic pris en charge/chiffrés :

  • Trafic entre nœuds : trafic quittant un pod sur un nœud et destiné à un pod sur un autre nœud.

Flux de trafic non pris en charge/non chiffrés

  • Trafic de pod de même nœud : trafic entre les pods sur le même nœud
  • Trafic réseau de nœud : trafic généré par le nœud lui-même destiné à un autre nœud

Vue d’ensemble de l’architecture

Le chiffrement WireGuard s’appuie sur Azure CNI alimenté par cilium pour sécuriser les communications entre nœuds au sein d’un système distribué. L’architecture utilise un agent WireGuard dédié qui orchestre la gestion des clés, la configuration de l’interface et les mises à jour d’homologue dynamiques. Cette section tente de fournir une explication détaillée

Diagramme de la conception WireGuard.

Agent WireGuard

Au démarrage, l’agent Cilium évalue sa configuration pour déterminer si le chiffrement est activé. Lorsque WireGuard est sélectionné comme mode de chiffrement, l’agent initialise un sous-système WireGuard dédié. L’agent wireguard est responsable de la configuration et de l’initialisation des composants requis pour appliquer le chiffrement WireGuard.

Génération de la clé

Une exigence fondamentale pour sécuriser la communication est la génération de paires de clés de chiffrement. Chaque nœud du cluster Kubernetes génère automatiquement une paire de clés WireGuard unique pendant la phase d’initialisation et distribue sa clé publique via l’annotation « network.cilium.io/wg-pub-key » dans l’objet de ressource personnalisée Kubernetes CiliumNode. Les paires de clés sont stockées en mémoire et pivotées toutes les 120 secondes. La clé privée sert d’identité confidentielle du nœud. La clé publique est partagée avec les nœuds homologues du cluster pour déchiffrer et chiffrer le trafic depuis et vers des points de terminaison gérés par Cilium s’exécutant sur ce nœud. Ces clés sont entièrement gérées par Azure, et non par le client, ce qui garantit une gestion sécurisée et automatisée sans intervention manuelle. Ce mécanisme garantit que seuls les nœuds avec des informations d’identification validées peuvent participer au réseau chiffré.

Création d’interface

Une fois le processus de génération de clés terminé, l’agent WireGuard configure une interface réseau dédiée (cilium_wg0). Ce processus implique la création et la configuration de l’interface avec la clé privée précédemment générée.

Comparaison avec le chiffrement de réseau virtuel

Azure offre plusieurs options pour sécuriser le trafic en transit dans AKS, notamment le chiffrement au niveau du réseau virtuel et le chiffrement basé sur WireGuard. Bien que les deux approches améliorent la confidentialité et l’intégrité du trafic réseau, elles diffèrent en termes d’étendue, de flexibilité et de déploiement. Cette section vous aide à comprendre quand utiliser chaque solution.

Utiliser le chiffrement de réseau virtuel quand

  • Vous avez besoin d’un chiffrement de couche réseau complet pour tout le trafic au sein du réseau virtuel : Le chiffrement de réseau virtuel garantit que tout le trafic, quelle que soit la charge de travail ou la couche d’orchestration, est automatiquement chiffré au fur et à mesure qu’il traverse le réseau virtuel Azure.

  • Vous avez besoin d’une surcharge minimale des performances : Le chiffrement de réseau virtuel utilise l’accélération matérielle dans les références SKU de machine virtuelle prises en charge, déchargeant le chiffrement du système d’exploitation vers le matériel sous-jacent. Cette conception offre un débit élevé avec une faible utilisation du processeur.

  • Toutes vos machines virtuelles prennent en charge le chiffrement de réseau virtuel : Le chiffrement de réseau virtuel dépend des références SKU de machine virtuelle qui prennent en charge l’accélération matérielle nécessaire. Si votre infrastructure se compose entièrement de références SKU prises en charge, le chiffrement de réseau virtuel peut être activé en toute transparence.

  • Vos configurations réseau AKS prennent en charge le chiffrement de réseau virtuel : Le chiffrement de réseau virtuel présente certaines limitations en matière de mise en réseau des pods AKS. Pour plus d’informations, consultez les scénarios pris en charge pour le chiffrement de réseau virtuel

Utiliser le chiffrement WireGuard quand

  • Vous souhaitez vous assurer que le trafic de votre application est chiffré sur l’ensemble des nœuds du réseau virtuel cependant, le chiffrement de réseau virtuel ne chiffre pas le trafic entre les nœuds sur le même hôte physique.

  • Vous souhaitez unifier le chiffrement dans des environnements multiclouds ou hybrides : WireGuard offre une solution indépendante du cloud, ce qui permet un chiffrement cohérent entre les clusters s’exécutant dans différents fournisseurs de cloud ou locaux.

  • Vous n’avez pas besoin ou souhaitez chiffrer tout le trafic au sein du réseau virtuel : WireGuard permet une stratégie de chiffrement plus ciblée idéale pour sécuriser les charges de travail sensibles sans entraîner la surcharge de chiffrement de tout le trafic.

  • Certaines références SKU de machine virtuelle ne prennent pas en charge le chiffrement de réseau virtuel : WireGuard est implémenté dans les logiciels et fonctionne indépendamment de la prise en charge matérielle des machines virtuelles, ce qui en fait une option pratique pour les environnements hétérogènes.

Considérations & limitations

• WireGuard n’est pas conforme à FIPS . • Le chiffrement WireGuard ne s’applique pas aux pods utilise la mise en réseau hôte (spec.hostNetwork : true), car ces pods utilisent l’identité de l’hôte au lieu d’avoir des identités individuelles.

Important

Le chiffrement WireGuard fonctionne au niveau logiciel, ce qui peut introduire une latence et avoir un impact sur les performances du débit. L’étendue de cet impact dépend de différents facteurs, notamment la taille de machine virtuelle (référence SKU de nœud), la configuration réseau et les modèles de trafic d’application. Notre benchmark indique que le débit est limité à 1,5 Gbit/s avec un MTU de 1500 ; Toutefois, les résultats peuvent varier en fonction des caractéristiques de la charge de travail et de la configuration du cluster. L’utilisation d’une référence SKU qui prend en charge MTU 3900 a entraîné un débit d’environ 2,5 fois plus élevé. Bien que le chiffrement WireGuard puisse être utilisé en même temps que les stratégies réseau, cela peut entraîner une dégradation des performances supplémentaire, avec un débit réduit et une latence accrue. Pour les applications sensibles à la latence ou au débit, nous vous recommandons vivement d’évaluer WireGuard dans un environnement hors production en premier. Comme toujours, les résultats peuvent varier en fonction des caractéristiques de la charge de travail et de la configuration du cluster.

Pricing

Important

Services avancés de mise en réseau de conteneurs est une offre payante. Pour plus d’informations sur la tarification, consultez Tarification des services avancés de mise en réseau de conteneurs.

Étapes suivantes

  • Last updated on