Chiffrement Cilium mTLS (préversion publique)

Le chiffrement mTLS Cilium fournit un chiffrement TLS (mTLS) transparent, mutuel et une authentification pour le trafic de pod à pod dans Kubernetes sans nécessiter de modifications de l'application ni introduire de pile réseau supplémentaire.

Il garantit que les charges de travail source et de destination sont authentifiées par chiffrement avant l’échange d’un trafic. Cette approche permet un modèle de mise en réseau de confiance zéro pour les charges de travail Kubernetes.

Tout le chiffrement et l’authentification se produisent sous la couche application, ce qui signifie que les charges de travail n’ont pas besoin d’être modifiées, reconstruites ou redémarrées pour bénéficier de mTLS.

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

Architecture

À un niveau élevé, Cilium mTLS sécurise le trafic en combinant l’émission d’identité, l’interception transparente du trafic et l’application du chiffrement au niveau de la charge de travail.

Chaque charge de travail reçoit une identité de chiffrement dérivée des attributs Kubernetes tels que l’espace de noms et ServiceAccount. Lorsque le trafic TCP pod-à-pod est lancé, le trafic est intercepté de manière transparente au niveau du nœud. Le trafic est ensuite authentifié et chiffré à l’aide du protocole TLS mutuel avant d’être transféré à la charge de travail de destination.

Le système se compose de trois composants de coopération :

• SPIRE : fournit l’identité de la charge de travail et l’émission de certificats.
• ztunnel : applique mTLS dans le plan de données.
• Cilium : installe des règles iptables qui redirigent le trafic sortant vers ztunnel sur le port 15001.

Ensemble, ces composants garantissent que l’authentification et le chiffrement se produisent de manière transparente et cohérente sur le cluster.

Modèle d’identité et d’authentification

Cilium mTLS utilise l’authentification mutuelle basée sur l’identité de charge de travail SPIFFE.

Chaque charge de travail reçoit une identité SPIFFE (SVID) dérivée de :

• Espace de noms Kubernetes
• Kubernetes ServiceAccount

Lorsqu’une charge de travail lance une connexion :

1. Le ztunnel source récupère un SVID valide pour la charge de travail.
2. Le ztunnel de destination valide l’identité présentée.
3. Les deux côtés effectuent une vérification mutuelle avant que le trafic ne soit autorisé à circuler.

Les décisions d’authentification sont basées sur l’identité de la charge de travail plutôt que sur l’emplacement réseau. Cette conception garantit que :

• Seules les charges de travail authentifiées peuvent communiquer.
• L’identité reste cohérente entre la reprogrammation et la mise à l’échelle.
• La confiance ne dépend pas de l’adressage IP ou de la topologie réseau.

Flux de chiffrement

Une fois l’authentification réussie, le trafic est protégé à l’aide du protocole TLS mutuel.

1. Trafic intercepté à l’intérieur de l’espace de noms du réseau de pods et redirigé vers l’instance ztunnel locale.
2. Le ztunnel source lance une session mTLS avec le ztunnel de destination.
3. Les certificats sont échangés et validés.
4. Les données d’application sont chiffrées avant la transmission.
5. Le ztunnel de destination déchiffre le trafic et le remet au pod cible.

Chaque paquet d’un pod inscrit est chiffré. Il n’existe aucune fenêtre en texte clair et aucun premier paquet supprimé. La connexion est conservée inline par ztunnel jusqu’à ce que le tunnel mTLS soit établi, puis le trafic circule bidirectionnellement via un tunnel HBONE (HTTP/2 CONNECT).

Composants de base

SPIRE (identité et confiance)

SPIRE (SPIFFE Runtime Environment) est responsable de la gestion des identités et des certificats de charge de travail. SPIRE a deux composants principaux : le serveur SPIRE et l’agent SPIRE.

Le serveur SPIRE agit en tant qu’autorité de certification du cluster. Il émet des certificats X.509 de courte durée (SVID) uniquement aux charges de travail autorisées à recevoir des identités. Il utilise l’attestation native Kubernetes, qui lie l'identité à des attributs tels que l’espace de noms et le compte de service, plutôt qu'aux propriétés réseau telles que les adresses IP.

Sur chaque nœud, l’agent SPIRE est chargé d’attester le nœud auprès du serveur SPIRE et de récupérer des certificats pour le compte des charges de travail locales. Les charges de travail communiquent uniquement avec l’agent SPIRE et ne communiquent jamais directement avec le serveur SPIRE.

SPIRE garantit que chaque identité de la tâche est :

• Vérifiable par chiffrement.
• Émis et renouvelés automatiquement.
• Lié aux primitives Kubernetes, et non aux adresses IP.
• Stable lors des redémarrages de pods et des événements de replanification.

Cette base d’identité permet de prendre des décisions d’approbation fortes et indépendantes de la topologie.

Ztunnel (plan de données mTLS)

Ztunnel est un proxy léger de couche 4 au niveau du nœud, responsable de l'application de mTLS entre les charges de travail. Il s’exécute en tant que DaemonSet, avec une instance par nœud, éliminant la nécessité de proxys sidecar par pod.

Lorsqu’une charge de travail lance une connexion TCP, ztunnel établit une session TLS mutuellement authentifiée avec l’instance ztunnel du nœud homologue. Il utilise des certificats obtenus auprès de SPIRE pour authentifier les deux côtés de la connexion avant d’autoriser le trafic à circuler.

Ztunnel applique les garanties suivantes :

• Les deux côtés d’une connexion doivent présenter des certificats de charge de travail valides.
• Les certificats sont vérifiés par rapport au domaine d’approbation de cluster.
• Le trafic est toujours chiffré sur le câble.
• Aucun recours au texte en clair n’est autorisé pour les charges de travail enrôlées.

En centralisant l’application mTLS au niveau du nœud, ztunnel fournit des propriétés de sécurité fortes sans augmenter la surcharge opérationnelle par pod.

Cilium (règles de redirection et inscription des pods)

Cilium est chargé de rendre mTLS transparent pour les applications.

Lorsqu’un espace de noms est étiqueté avec « io.cilium/mtls-enabled=true », l’agent Cilium inscrit tous les pods dans cet espace de noms. Il entre dans l’espace de noms réseau de chaque pod et installe des règles iptables qui redirigent le trafic sortant vers ztunnel sur le port 15001.

Cilium transmet également les métadonnées de charge de travail, telles que l’UID pod, à ztunnel et s’intègre à l’opérateur Cilium pour inscrire des identités de charge de travail auprès de SPIRE.

Du point de vue de l’application, la communication continue à utiliser des sockets TCP standard. Le chiffrement et l’authentification sont appliqués entièrement sous la couche application, ce qui ne nécessite aucune modification du code.

Limites de portée et de confiance

Inscription de l’espace de noms

Cilium mTLS est une option à activer et est délimité au niveau de l’espace de noms. Un espace de noms doit être explicitement étiqueté pour permettre l'application de mTLS. Une fois activé, tous les pods de cet espace de noms sont soumis à l’authentification et au chiffrement obligatoires.

Les pods dans les espaces de noms non inscrits ne sont pas affectés. Cette conception permet le déploiement incrémentiel et l’adoption intermédiaire dans les environnements.

Modèle d’application

Le chiffrement est appliqué uniquement lorsque les deux pods sont inscrits. Le trafic entre les charges de travail inscrites et non inscrites continue en clair, sans provoquer de problèmes de connectivité ni d’échecs bloquants.

Considérations et limitations

• La fonctionnalité est disponible uniquement sur les clusters utilisant Azure CNI optimisé par Cilium avec Advanced Container Networking Services (ACNS) activé.
• mTLS est activé au niveau de l’espace de noms. Tous les pods d’un espace de noms inscrit participent à mTLS. L’opt-in ou le retrait au niveau du pod n’est pas pris en charge.
• Cilium mTLS protège actuellement le trafic pod-à-pod basé sur TCP. Il ne chiffre pas ou authentifie actuellement d’autres protocoles, y compris UDP.
• Dans la phase actuelle, l’application de la stratégie réseau L4/L7 n’est pas prise en charge avec mTLS.
• Vous ne pouvez pas utiliser votre propre autorité de certification (CA). SPIRE agit en tant qu’autorité de certification de cluster et gère l’émission et la rotation des certificats.
• L’activation de mTLS et WireGuard sur le même cluster n’est pas prise en charge.
• L'activation simultanée du chiffrement mTLS par Istio et Cilium n'est pas prise en charge.
• Le chiffrement mTLS pour le trafic entre clusters n’est pas pris en charge.
• L’intégration nécessite la prise en charge des iptables dans le noyau et ne peut pas être utilisée avec des environnements qui ne prennent pas en charge les iptables (par exemple, certains runtimes de conteneur minimal).
• Les pods sans chemin d’accès d’espace de noms réseau (par exemple, les pods en réseau hôte) ne peuvent pas être inscrits dans ztunnel et sont exclus pendant le processus d’inscription.

Tarification

Étapes suivantes

• Découvrez comment appliquer le chiffrement Cilium mTLS sur AKS.

• Pour plus d’informations sur Advanced Container Networking Services pour Azure Kubernetes Service (AKS), consultez Qu’est-ce que Advanced Container Networking Services pour Azure Kubernetes Service (AKS) ?.