Des connexions privées entre serveurs, sans VPN ni port ouvert
Comment services, bases de données et serveurs dans différents clouds se joignent dans Opfield : connexions sortantes en mTLS, Secure Links via des relais, bases privées avec un utilisateur par liaison, et ce qu'Opfield vous laisse.
Par l’équipe Opfield5 min de lectureMis à jour
Un cas courant : l'API tourne chez un fournisseur cloud, sa base de données chez un autre, et le site public sur un troisième serveur. Pour les relier, les équipes montent en général un VPN entre les serveurs ou ouvrent le port de la base en le limitant à une liste d'adresses. Les deux fonctionnent, et les deux ajoutent quelque chose à maintenir et quelque chose à attaquer.
Opfield procède autrement. Vos serveurs ne font que des connexions sortantes, et le trafic privé entre eux passe par des relais, sur des connexions authentifiées. Voici comment cela fonctionne, et quelles en sont les limites.
Les serveurs se connectent vers l'extérieur, rien ne les attend
Vos serveurs n'ont besoin d'aucun port de gestion ouvert. Chaque serveur fait tourner de petits démons Opfield qui se connectent vers le relais d'Opfield, normalement sur 9443/tcp. La connexion est toujours en TLS, et les démons n'exposent aucune API de gestion sur le réseau. Un serveur dans n'importe quel cloud, ou derrière un NAT, peut rejoindre la flotte du moment qu'il atteint le relais.
Chaque serveur prouve qui il est
Ajouter un serveur demande une commande d'installation. Elle contient un jeton d'enrôlement à usage unique et l'empreinte du certificat d'Opfield. Au premier démarrage, le démon vérifie ce certificat avant d'envoyer quoi que ce soit. Il n'envoie le jeton que si l'empreinte correspond, si bien qu'un mauvais enregistrement DNS ou un proxy sur le chemin ne peut pas l'intercepter.
Opfield délivre ensuite au serveur son propre certificat mTLS, émis par l'autorité de certification interne d'Opfield. Le démon retire le jeton de sa configuration et se reconnecte avec le certificat. Dès lors, le certificat est l'identité du serveur, et Opfield le vérifie sur chaque flux. Il n'y a pas de secret partagé qui pourrait fuiter, et supprimer un serveur révoque son certificat : l'ancien démon ne peut plus se reconnecter en tant que ce serveur.
Le trafic public atteint un service sans port publié
Une route sur un serveur nginx public peut pointer vers un conteneur, un déploiement ou un service Compose situé sur un autre serveur. Opfield relie les deux par un Secure Link : une connexion privée authentifiée via le relais. Le service ne publie aucun port sur l'hôte, et la route le suit par son identité, si bien qu'un redémarrage ou une nouvelle version ne demande aucune modification de la route. Les Secure Links sont disponibles dans toutes les offres, Community comprise.
Les bases de données restent privées
PostgreSQL, les stores clé-valeur et ClickHouse gérés sont privés par défaut. Quand vous liez une application à une base, Opfield ajoute un réseau privé au conteneur, lui fournit les variables de connexion et fait passer le trafic dans un tunnel authentifié via le relais. La base n'écoute sur aucun port public.
Chaque liaison reçoit son propre utilisateur de base : un rôle Postgres dédié, un utilisateur ACL du store clé-valeur ou un utilisateur ClickHouse. L'application ne reçoit jamais les identifiants du propriétaire, et supprimer la liaison révoque cet utilisateur. Si un outil externe a besoin d'un accès direct, publier un port de base est un choix explicite. Il exige l'authentification de la base, et Opfield n'ouvre pas le pare-feu de l'hôte pour cela. Les bases de données gérées demandent Personal ou plus.
Le relais tourne comme un service à part, de longue durée, séparé de l'application Opfield. Les mises à jour ordinaires d'Opfield ne le recréent pas : les sessions de base déjà ouvertes continuent pendant que l'application redémarre.
Plus d'un relais
Le trafic privé n'a pas à dépendre d'une seule machine. En plus du relais fourni avec Opfield, vous pouvez ajouter des relais sur d'autres hôtes pour former un Relay Pool. Le domaine de panne d'un relais est son hôte physique : deux relais sur le même hôte ne comptent pas comme redondants.
Les nouvelles connexions sont réparties entre les relais prêts. Quand vous videz un relais (drain), les nouvelles connexions partent vers les autres et les flux existants continuent. Les mises à jour des relais sont signées et déployées un relais à la fois. Les applications voient une seule liaison logique et n'ont pas besoin de savoir quel relais la porte. Opfield reste le plan de contrôle : vos données passent par les relais, pas par l'application Opfield.
Ce qu'Opfield ne fait pas
Ce n'est pas un VPN, et cela ne cherche pas à en être un. Opfield n'ouvre pas de pare-feu, ne fournit pas de traversée de NAT et ne crée pas de réseau overlay. Les serveurs restent indépendants, sans relation de confiance établie entre eux.
Quelques points restent de votre ressort :
- Chaque serveur doit atteindre les relais qui lui sont attribués, sur
9443/tcppar défaut. Un relais est le seul endroit qui accepte des connexions entrantes de vos serveurs. - Les serveurs nginx publics ont besoin de
80/tcpet443/tcpouverts pour le trafic web. - Un Secure Link protège le transport et le choix de la cible. C'est toujours votre application qui décide qui peut l'appeler.
En savoir plus
La documentation décrit pas à pas l'enrôlement des nœuds, le Relay Pool, les upstreams sécurisés et les liaisons aux bases de données, y compris les règles de pare-feu pour chaque type de serveur.