Découvrez en détail la nouvelle fonctionnalité Private Networks

Nous sommes heureux d'annoncer le lancement de Private Networks. Dans cet article, nous expliquons ce que comprend le nouveau produit Private Networks avant d'entrer dans les détails techniques de sa mise en œuvre.

Les Private Networks

Les Private Networks (réseaux privés) sont une nouvelle fonctionnalité qui permet aux conteneurs d'un ensemble d'applications de partager un réseau privé sécurisé commun qu'ils peuvent utiliser pour communiquer entre les conteneurs de ces applications sans avoir à passer par des points de terminaison publics.

Jusqu'à présent, dans l'architecture Scalingo, tous les conteneurs sont déployés de manière isolée les uns des autres. Ils ne peuvent absolument pas communiquer entre eux.

De plus, Scalingo obligeait jusque là un conteneur web à écouter la variable d'environnement PORT et à être exposé sur Internet. Mais pour certains cas d'utilisation, nos clients ont souligné qu'ils avaient besoin de pouvoir écouter sur n'importe quel port, sans exposer l'application sur Internet.

Grâce à cette nouvelle fonctionnalité, vous pouvez déployer une application au sein d'un réseau privé non exposé sur Internet. Cette application peut écouter sur n'importe quel port TCP et UDP. Cela ouvre la voie à de nouveaux cas d'utilisation et à de nouvelles façons d'utiliser la plateforme Scalingo.

Cet article de blog vous présente les étapes techniques que nous avons suivies pour franchir cette étape importante pour Scalingo : offrir des réseaux privés par projet aux clients de Scalingo !

L’architecture jusqu'à présent

Dans l'architecture de Scalingo, toutes les applications sont déployées dans des conteneurs Docker. Un conteneur Docker est un network namespace Linux (généralement abrégé netns) situé dans le network namespace root du serveur :

Le network namespace de l'application (appelé « app netns ») contient une seule interface eth0 pour communiquer avec le monde extérieur, via le bridge Docker local. Le seul port exposé sur le réseau de Scalingo est celui défini dans la variable d'environnement PORT. C'est donc le seul port utilisable pour communiquer avec l'application.

Avec cette configuration, seuls les conteneurs web se voient attribuer un PORT. Les autres types de conteneurs ne peuvent écouter sur aucun port.

La première exigence à laquelle nous voulions répondre est de regrouper les conteneurs d'applications de manière privée. Nous voulions que les conteneurs d'un client se trouvent dans le même réseau privé afin de permettre la communication entre eux.

Grouper les conteneurs grâce à VXLAN

Le choix de VXLAN n'a pas été immédiat. Nous avons d'abord étudié différentes technologies de réseaux privés. La raison pour laquelle nous avons finalement décidé d'utiliser VXLAN dépasse le cadre de cet article, mais cette solution s'est avérée idéale pour regrouper les conteneurs de manière privée chez Scalingo.

VXLAN est une technologie déjà bien connue chez Scalingo. Lorsque nous avons travaillé sur la configuration haute disponibilité des bases de données, nous avons déjà utilisé les VXLAN pour masquer les nœuds de base de données au monde extérieur. Nous avons open sourcé la technologie pour créer dynamiquement des réseaux privés VXLAN et l’avons nommée SAND.

VXLAN (Virtual Extensible LAN) est une technologie de virtualisation réseau qui vise à surmonter les limites des réseaux traditionnels de couche 2. VXLAN fonctionne en encapsulant des trames Ethernet dans des paquets UDP, ce qui permet de créer des réseaux virtuels sur une infrastructure physique.

Pour notre nouvelle offre de Private Networks, VXLAN sert de technologie centrale pour regrouper les conteneurs. Elle garantit qu'ils sont traités comme s'ils appartenaient au même réseau local, même s'ils sont répartis sur différentes machines virtuelles partagées.

L'utilisation de VXLAN dans le contexte de Scalingo offre des avantages :

• Scalabilité : VXLAN peut prendre en charge jusqu'à 16 millions de réseaux logiques, ce qui le rend idéal pour les déploiements de conteneurs à grande échelle.
• Isolation : chaque réseau VXLAN est isolé des autres, ce qui garantit que les conteneurs d'un réseau ne peuvent pas communiquer accidentellement avec ceux situés en dehors de celui-ci.
• Flexibilité : VXLAN abstrait la couche réseau physique, ce qui facilite la configuration des Software-Defined Networks (SDN).

D’un point de vue technique, intégrer le conteneur dans un VXLAN consiste à ajouter un nouveau network namespace et un groupe d'interfaces :

Nous avons créé un network namespace pour le VXLAN qui contient une interface Ethernet virtuelle (veth) nommée app-1-web-1-veth0 afin de communiquer avec l'interface à l'intérieur du conteneur Docker (vxlan-1-veth0).

Ce VXLAN contient également une interface bridge (br0). Si un deuxième conteneur au sein du même VXLAN est démarré sur le même serveur, nous créerions une deuxième veth dans le network namespace du VXLAN et le connecterions également à ce bridge.

Enfin, il existe une interface VXLAN (vxlan0) chargée d'encapsuler/décapsuler la trame Ethernet à l'intérieur du paquet UDP et d'ajouter un identifiant réseau du VXLAN (VNI). Dans la terminologie VXLAN, cette interface est appelée « VXLAN tunnel endpoint » (VTEP).

On peut noter qu'il est toujours possible pour l'application de communiquer avec Internet via l'interface eth0 connectée au bridge Docker sur le serveur.

Cette configuration constitue une bonne base, mais elle ne répond pas à toutes les exigences que nous avons pour le produit Private Networks. Même si cela n'est pas encore utilisable, une évolution consistera à ajouter la possibilité pour un conteneur de communiquer dans plusieurs réseaux privés.

Se préparer pour les multi-réseaux privés

En termes d'architecture, la configuration VXLAN est déjà prête à prendre en charge un conteneur dans plusieurs réseaux privés :

En termes de code, SAND n'était pas prêt à prendre en charge un conteneur au sein de plusieurs réseaux privés. Cette étape ne nécessite pas beaucoup de travail, et nous sommes impatients de vous offrir la possibilité d'avoir un conteneur au sein de plusieurs réseaux privés !

Plus de confidentialité grâce au chiffrement

Si VXLAN permet de regrouper et d'acheminer le trafic des conteneurs, il n'offre pas en soi une sécurité élevée pour les données en transit. C'est là qu'intervient WireGuard, un protocole VPN moderne.

WireGuard est réputé pour sa simplicité, ses performances élevées et sa puissance cryptographique. WireGuard garantit que les données transitant entre les conteneurs sont protégées contre l'espionnage ou la falsification. Le protocole utilise des primitives cryptographiques de pointe (telles que Curve25519, ChaCha20-Poly1305 et BLAKE2s) pour offrir une sécurité robuste avec un minimum de surcoût. De plus, il est déjà disponible prêt à l'emploi dans tous les noyaux Linux modernes.

Nous voulons que le network namespace de l'application dispose d'une interface unique pour communiquer au sein du réseau privé. Et cette interface doit chiffrer toutes les communications. Pour ce faire, nous devons créer un network namespace supplémentaire :

Nous introduisons un nouveau network namespace (binding netns) dans lequel les veth VXLAN sont déplacés. Il y a ensuite une petite astuce que nous devons expliquer pour comprendre comment l'interface WireGuard (wg0) communique avec le binding network namespace.

WireGuard possède une fonctionnalité unique : lorsqu'une interface WireGuard est créée, elle mémorise le namespace dans lequel elle a été initialement créée. Même si l'interface est ensuite déplacée vers un autre namespace, elle conserve en mémoire son namespace d'origine. En effet, la socket UDP qui envoie et reçoit réellement les paquets chiffrés est créée dans le namespace d'origine.

Dans notre configuration, cela signifie que nous créons l'interface WireGuard dans le binding network namespace, puis que nous la déplaçons vers le namespace de l'application. Tous les paquets en clair envoyés dans l'interface WireGuard sont transférés de manière chiffrée via la socket UDP qui reste dans le binding network namespace.

En résumé

Nous avons décrit une configuration complète avec des network namespaces interconnectés pour créer des réseaux privés chiffrés. Résumons tout cela à l'aide d'un exemple d'application contenant deux types de conteneurs : web et backend. Dans cet exemple, nous voulons mettre en évidence le trajet d'un paquet IP depuis le conteneur de type web vers le backend (adresse IP 10.240.0.2) :

L'application envoie le paquet IP via l'interface WireGuard (wg0) (étape 1). WireGuard conserve une liste des pairs potentiels avec lesquels ce conteneur peut communiquer, associés à leurs clés publiques. WireGuard utilise la clé publique de la destination pour chiffrer le paquet. Le paquet est encapsulé dans un datagramme UDP.

Ce datagramme passe par la socket UDP qui est restée dans le binding network namespace (étape 2). Une table de routage dans binding network namespace dirige le datagramme vers le network namespace du VXLAN via l'interface vxlan-1-veth0.

Le datagramme est envoyé à l'interface VXLAN (vxlan0) via l'interface br0 (étape 3). L'interface VXLAN reçoit une trame Ethernet qui contient le datagramme UDP. Ce datagramme contient le paquet IP d'origine envoyé par l'application. VXLAN encapsule la trame Ethernet reçue dans un datagramme UDP qui est envoyé au network namespace du VXLAN de destination.

Dans le network namespace du VXLAN de destination, la trame Ethernet est décapsulée pour obtenir le datagramme UDP WireGuard (étape 4). Il est envoyé au binding network namespace via l'interface app-2-web-1-veth0.

Le datagramme est transféré via la socket UDP WireGuard pour être envoyé au network namespace de l'application (étape 5). Lorsqu'il est reçu sur l'interface WireGuard (étape 6), le datagramme est décapsulé et déchiffré afin d'obtenir le paquet IP d'origine. Ce paquet est transféré au conteneur backend.

Les noms de domaine internes

À partir de cet exemple, nous voyons qu'il est important pour une application de déterminer l'adresse IP des autres conteneurs du même réseau privé. C'est pourquoi nous introduisons les noms de domaine internes. Un nom de domaine interne est composé du numéro du conteneur (facultatif), du type de conteneur (facultatif), de l'ID de l'application, de l'ID du réseau privé et d'un identifiant de réseau interne commun (private-network.internal).

Voici quelques exemples avec une application ap-a71da13f-7c70-4c00-a644-eee8558d8053 et un réseau privé pn-ad0fd6a1-d05e-40ea-bf63-c4f8a75a9d8c :

• ap-a71da13f-7c70-4c00-a644-eee8558d8053.pn-ad0fd6a1-d05e-40ea-bf63-c4f8a75a9d8c.private-network.internal.

  Enregistrements DNS de type A vers les conteneurs web. Les conteneurs web sont les conteneurs par défaut contactés lors de l'utilisation du nom de domaine de l'application (préfixes facultatifs exclus).

• web.ap-a71da13f-7c70-4c00-a644-eee8558d8053.pn-ad0fd6a1-d05e-40ea-bf63-c4f8a75a9d8c.private-network.internal.

  Enregistrements DNS de type A vers les conteneurs web.

• 1.web.ap-a71da13f-7c70-4c00-a644-eee8558d8053.pn-ad0fd6a1-d05e-40ea-bf63-c4f8a75a9d8c.private-network.internal.

  Enregistrements DNS de type A vers le premier conteneur web.

• worker.ap-a71da13f-7c70-4c00-a644-eee8558d8053.pn-ad0fd6a1-d05e-40ea-bf63-c4f8a75a9d8c.private-network.internal.

  Enregistrements DNS de type A vers les conteneurs worker

• 1.worker.ap-a71da13f-7c70-4c00-a644-eee8558d8053.pn-ad0fd6a1-d05e-40ea-bf63-c4f8a75a9d8c.private-network.internal.

  Enregistrements DNS de type A vers le premier conteneur worker

Ces noms de domaine peuvent être déduits à partir de l'identifiant de l'application, de l'identifiant du réseau privé et de la formation de l'application. Les identifiants de l'application et du réseau privé sont injectés dans l'environnement de l'application au moment de l'exécution.

Vous pouvez également lister ces noms de domaine en utilisant le CLI de Scalingo :

scalingo --app my-app private-networks-domain-names

Conclusion

Voilà, c'est l'histoire (plutôt technique) de la manière dont nous proposons à nos clients un nouveau produit appelé Private Networks. Ajoutez un nom de domaine pour tous les conteneurs du réseau privé qui résout l'adresse IP à l'intérieur du réseau privé, et ce produit vous permet de déployer des applications web qui ne sont pas exposées sur Internet.

Notre nouvelle solution de Private Networks, qui combine la puissance de VXLAN et de WireGuard, offre une couche réseau innovante, évolutive et sécurisée pour vos applications déployées sur la plateforme Scalingo.

Le produit Private Networks est conçu pour assurer une communication sécurisée et fluide entre vos applications. Grâce à ce nouveau produit, vous pouvez désormais déployer des applications web qui ne sont pas exposées sur Internet. Mieux encore, il est facile à utiliser et entièrement intégré à notre offre de Platform-as-a-Service, ce qui vous permet de vous concentrer sur l'essentiel : créer et exécuter vos applications.

Intéressés par Private Networks ? Contactez notre équipe de support via le chat intégré au tableau de bord ou par e-mail à l'adresse support@scalingo.com.

Restez connecté à ce blog pour connaître les dernières actualités concernant cette fonctionnalité, d'autres nouveautés sont à venir.