Comment nous isolons les tenants au niveau du noyau

Le problème des frontières molles

Des conteneurs classiques sur un noyau partagé sont un format d'empaquetage, pas une frontière de sécurité. Par défaut, tous les conteneurs d'un hôte partagent la même surface d'attaque du noyau, le même ordonnanceur et les mêmes files d'IO. Si un tenant découvre une vulnérabilité du noyau — ou lance simplement une fork bomb — le rayon d'impact est la machine entière, y compris tous les autres clients qu'elle héberge.

Les voisins bruyants sont la version quotidienne de la même défaillance. Sans limites imposées, le traitement par lots d'un tenant peut voler des cycles CPU, saturer les IO disque et expulser de la mémoire les pages d'un autre tenant. La multi-location hostile exige des frontières que le noyau fait respecter, pas des conventions qu'une charge de travail bien élevée daigne suivre.

Namespaces, cgroups et seccomp

Sur Anested Cloud, chaque charge de travail d'un tenant reçoit ses propres namespaces PID, réseau et de montage. Les processus d'un tenant ne peuvent littéralement ni voir, ni signaler, ni tracer ceux d'un autre ; chaque charge de travail voit sa propre vue privée du système de fichiers et sa propre pile réseau. C'est le noyau Linux qui l'impose à chaque appel système, et non un moteur de règles susceptible d'être mal configuré.

Au-dessus des namespaces, nous superposons le contrôle de ressources cgroup v2 et le filtrage des appels système par seccomp. Des quotas plafonnent le temps CPU, la mémoire et les IO de bloc par tenant : un processus emballé se bride lui-même au lieu de brider l'hôte. Les profils seccomp rejettent les appels système dont une charge de travail n'a que faire — coupant des classes entières d'exploits du noyau avant qu'ils n'atteignent du code vulnérable.

• Namespace réseau dédié, avec sa propre interface virtuelle et ses propres règles de pare-feu
• Quotas cgroup v2 pour le CPU, la mémoire et les IO de bloc
• Profils seccomp n'autorisant que les appels système dont la charge de travail a besoin
• Systèmes de fichiers racine en lecture seule, avec des montages inscriptibles explicites

Isolation réseau par tenant

Chaque tenant vit sur son propre réseau virtuel privé. Les règles de pare-feu sont générées par tenant et refusent tout par défaut : il n'existe aucune route entre les charges de travail d'un tenant et celles d'un autre, si bien que le trafic est-ouest entre tenants est impossible par construction. Scanner les ports de son voisin depuis un VPS Anested ne renvoie même pas de ports fermés — les paquets ne quittent jamais votre namespace réseau.

Le trafic public entre par le proxy de bordure et nulle part ailleurs. TLS se termine en bordure, les requêtes sont routées vers le réseau d'exactement un tenant, et les services internes n'acceptent jamais de connexions venant de l'extérieur de leur propre segment. Résultat : une topologie où la seule surface joignable est celle que vous avez délibérément exposée.

Ce que cela change pour les bases de données

Les mêmes murs s'appliquent à chaque base de données managée PostgreSQL, MongoDB et MySQL que nous exploitons. Chaque instance est confinée par ses propres namespaces, ses limites cgroup v2 et son profil seccomp : la requête lente ou la construction d'index incontrôlée d'un tenant ne peut pas priver la base d'un autre de CPU, de mémoire ou d'IO. Votre latence p99 dépend de votre charge de travail, pas de celle de votre voisin.

Les chaînes de connexion sont limitées à chaque base et ne se résolvent qu'à l'intérieur du réseau du tenant propriétaire. Même un identifiant divulgué est inutilisable depuis le segment d'un autre tenant, car les paquets ne peuvent tout simplement pas y parvenir. L'isolation au niveau du noyau et du réseau signifie que le contrôle d'accès de la base n'est pas votre dernière ligne de défense — c'est l'une parmi plusieurs.

La défense en profondeur, par défaut

Aucune couche n'est présumée parfaite. Les hôtes sont corrigés selon un calendrier progressif, avec migration à chaud lorsque c'est possible ; les noyaux sont maintenus à jour face aux CVE connues ; et chaque couche est surveillée à la recherche d'anomalies — des refus d'appels système inattendus au trafic inter-namespaces qui ne devrait jamais exister. Chaque composant interne s'exécute avec le strict minimum de privilèges, afin que la compromission d'un service ne se propage pas.

Rien de tout cela n'est une option réservée aux entreprises. L'isolation au niveau du noyau, le réseau par tenant et les quotas de ressources s'appliquent à chaque charge de travail sur Anested Cloud — y compris l'offre gratuite. Une sécurité qui dépend de votre formule de facturation n'est pas de la sécurité ; c'est une page de tarifs.