Nous sommes ravis d’annoncer le lancement de la bêta privée de notre fonctionnalité très attendue Private Networks. Découvrez-la dès maintenant !
Introduits il y a quelques mois, les Projets offrent une nouvelle manière d’organiser vos applications et vos ressources par service, produit, client, environnement ou équipe.
S’appuyant sur cette base, Private Networks équipe chaque projet d’un réseau privé dédié qui connecte vos services et sécurise leurs communications. Fidèles à notre mission de simplifier le quotidien des développeurs, nous avons conçu une solution prête à l’emploi, ne nécessitant ni configuration complexe ni expertise réseau, et proposée sans coût supplémentaire.
Vos projets et applications peuvent ainsi en bénéficier dès les premières phases de développement, sans compromis entre sécurité et agilité.
Afin d’améliorer notre infrastructure de manière transparente, sans impact sur vos workflows ni sur la disponibilité de vos applications, Private Networks s’intègre harmonieusement à votre configuration existante.
Un réseau supplémentaire basé sur VXLAN, sécurisé par WireGuard, connecte l’ensemble des applications et de leurs conteneurs, permettant des communications maillées privées et sécurisées. Pour les lecteurs les plus techniques, nous détaillerons ces mécanismes dans un prochain article.
Le comportement des processus web reste inchangé. Le trafic Internet continue de leur parvenir via votre nom de domaine. Ils peuvent ensuite transmettre ce trafic à n’importe quel conteneur au sein de leur réseau privé, y compris leurs propres processus non exposés publiquement et ceux des autres applications du même projet.
Pour plus de détails, nous vous invitons à consulter notre documentation.
Chaque conteneur se voit attribuer un nom de domaine privé suivant le format :
<container-number (optionnel)>.<container-type (optionnel)>.<application-id>.<private-network-id>.private-network.internal
Ce nom de domaine résout vers l’adresse IP privée (ou les adresses IP privées) des conteneurs de l’application et n’est accessible qu’au sein du réseau privé du projet.
Afin de simplifier leur intégration, nous avons également introduit de nouvelles variables d’environnement d’exécution :
SCALINGO_APPLICATION_ID : identifiant unique de l’applicationSCALINGO_PRIVATE_NETWORK_ID : identifiant unique du réseau privé, également inclus dans le nom d’hôte du conteneurSCALINGO_PRIVATE_HOSTNAME : nom d’hôte complet du conteneur, particulièrement utile pour l’identification précise des conteneurs dans les logs et pour le monitoringPour inspecter les enregistrements DNS depuis un conteneur one-off, vous pouvez utiliser des commandes telles que :
host <application-id>.<private-network-id>.private-network.internal
Exemple de résultat :
<application-id>.<private-network-id>.private-network.internal has address 10.240.0.4
Au sein d’un réseau privé, il n’existe aucune restriction liée à HTTP ou au port par défaut imposé par la variable d’environnement PORT. Vos processus, conteneurs et microservices peuvent communiquer librement en utilisant les ports et protocoles nécessaires.
Private Networks permet aux processus que vous choisissez de rendre privés de communiquer dans un environnement isolé. En exposant publiquement uniquement les services nécessaires, vous réduisez votre surface d’attaque et renforcez la sécurité globale de vos applications.
L’adoption d’une convention de nommage DNS standardisée facilite les interactions entre services. Vos conteneurs peuvent se connecter de manière déterministe aux autres processus, vous faisant gagner un temps précieux en développement comme en exploitation.
Renommer un processus web (par exemple en backend ou privateweb) limite sa visibilité au réseau privé du projet. Cette approche est particulièrement adaptée aux applications s’exécutant derrière un proxy (voir l’exemple ModSecurity ci-dessous).
Attention toutefois : renommer un processus web entraîne certaines limitations. Les fonctionnalités reposant sur les routeurs publics ne sont disponibles que pour les processus exposés publiquement : métriques opérationnelles, autoscaling basé sur le nombre de requêtes par minute et par conteneur, domaines personnalisés, ainsi que certaines options de routage.
Afin de rendre ce choix plus simple et réversible, nous prévoyons d’introduire une option, similaire à celle existant pour les bases de données, permettant de désactiver l’exposition publique d’un processus web sans avoir à le renommer.
De nombreux clients Scalingo utilisaient déjà différentes stratégies d’authentification, telles que le filtrage basé sur des en-têtes HTTP, afin de bloquer le trafic non autorisé.
Grâce à Private Networks, vous pouvez désormais isoler complètement vos applications en n’exposant publiquement que votre proxy ModSecurity, tout en protégeant les services sensibles au sein de votre réseau privé.
La gestion d’architectures microservices a toujours été complexe, notamment en matière de découverte de services et de communication inter-services. Private Networks garantit désormais que vos conteneurs Scalingo peuvent se découvrir et communiquer entre eux de manière sécurisée.
Jusqu’à présent, l’organisation et l’interconnexion de services multi-niveaux étaient complexes. Grâce au DNS privé et au réseau privé du projet, le déploiement d’architectures n-tiers devient plus simple : vous gagnez en scalabilité tout en n’exposant à Internet que les services nécessaires.
De nombreuses applications bénéficient de communications internes sans restriction de protocole ou de port. Nous publierons prochainement un guide dédié au déploiement de Keycloak en cluster afin d’atteindre une haute disponibilité.
Si vous avez d’autres idées ou des cas d’usage complémentaires, n’hésitez pas à nous contacter pour en discuter !
Nous ouvrons cette fonctionnalité à un nombre limité de clients. Pour en bénéficier en avant-première, inscrivez-vous à la bêta et partagez-nous vos cas d’usage.
Dans les prochaines semaines, nous publierons également davantage de détails techniques sur la conception et la mise en œuvre de Private Networks chez Scalingo.