Faites tourner des dizaines de conteneurs sur un serveur sans sacrifier l'isolation.
Le partage mémoire KSM tasse la densité dans le bare-metal. Firecracker + LXC imposent l'isolation par container. L'inguessabilité d'URL, la ségrégation de realms et le firewall au niveau host viennent par-dessus — chacun peut tomber, et les autres arrêtent encore l'explosion.
KSM · LXC + Firecracker · AES-256 · keyspace URL 2^192 · défense en profondeur
Pages partagées, mémoire séparée.
Kernel Samepage Merging fusionne les pages mémoire identiques entre conteneurs en copies physiques uniques. Une image Debian de base, un runtime Node, une install Postgres — tous les octets que chaque conteneur du serveur partage sont comptés une seule fois en RAM.
Pages identiques dédupliquées
Les pages RAM au contenu identique (librairies courantes, OS de base, runtimes partagés) sont fusionnées. 30 conteneurs Node sur un serveur consomment beaucoup moins de mémoire que 30× un container.
Isolation préservée
Les conteneurs ne peuvent pas lire la RAM les uns des autres. KSM est une optimisation de stockage — les pages fusionnées deviennent copy-on-write. Toute écriture forke instantanément une copie privée.
Pas de travail côté conteneur
KSM est au niveau kernel. Les applications n'ont pas besoin de le savoir. Le conteneur voit une mémoire Linux normale ; l'host voit la déduplication physique.
Bénéfice dépendant de la charge
Le bénéfice scale avec ce que les conteneurs partagent. Stacks similaires = énorme dédup. Apps très différentes = moins de dédup, mais les pages OS de base fusionnent quand même.
LXC + Firecracker. Namespaces kernel + micro-VMs.
Hoody utilise un modèle d'isolation à deux couches. LXC fournit une isolation conteneur Linux légère via les namespaces. Firecracker ajoute des frontières micro-VM assistées par le hardware là où une séparation plus forte compte. Le kernel host est durci (base Linux 7.1-hoody) avec un filtrage seccomp des syscalls par-dessus.
Namespaces LXC
Process, network, mount, user, PID, IPC — chaque conteneur a sa propre vue du kernel. Mécanisme Linux standard, éprouvé à grande échelle.
Instances VM dédiées
Instances de machines virtuelles complètes en option pour les charges qui exigent une isolation kernel totale — un mur plus solide que les seuls namespaces, provisionnées à la demande plutôt que des conteneurs système.
Kernel durci
Base Linux 7.1-hoody avec durcissement sécurité. Les filtres seccomp restreignent les syscalls qu'un conteneur peut faire.
Baseline bare-metal
Les conteneurs tournent sur du hardware possédé par l'utilisateur. Pas d'hyperviseur partagé avec d'autres tenants. Pas de canal auxiliaire de voisin gênant venant du provider cloud au-dessus.
AES-256 partout où les données touchent le disque.
Chiffrement filesystem, swap chiffré, fichiers temporaires chiffrés. Déverrouillage à distance via sous-partition. Le disque est du chiffré ; le déchiffrement se passe en RAM au boot.
Filesystem AES-256
Chaque octet écrit sur disque est chiffré. Perds le drive, perds rien de lisible.
Swap + temp chiffrés
Les pages de swap et les fichiers temporaires ne touchent jamais le disque en clair. Les dumps mémoire kernel sont chiffrés aussi.
Déverrouillage à distance par sous-partition
Le flux de boot supporte le déchiffrement à distance via SSH dans l'initramfs. Pas de clés disque physiquement stockées avec les données.
2^192 combinaisons. La force brute n'est pas l'attaque.
Les IDs de projet sont 24 caractères hexadécimaux. Les IDs de conteneur sont 24 caractères hexadécimaux. Une URL valide demande les deux. Le keyspace est 2^192 — à mille milliards d'essais par seconde, l'énumération prend plus longtemps que l'âge de l'univers. L'inguessabilité est un défaut de départ, pas la seule couche.
Keyspace de paire
2^192
Pour énumérer à 1T/s
plus long que l'âge de l'univers
Couches additionnelles disponibles
JWT · Mot de passe · IP · Token
Open-by-URL est le mode de départ. Verrouille n'importe quelle URL avec JWT, HTTP Basic, CIDR IP, ou bearer token via /platform/proxy — pas de code applicatif requis.
Six couches indépendantes. Une faille en laisse cinq autres.
La sécurité est une stack, pas une porte. Chaque couche est efficace indépendamment ; ensemble elles rendent une faille unique survivable.
Inguessabilité d'URL
Keyspace 2^192 sur les combos projet+container. L'URL elle-même est le premier secret.
Isolation conteneur
Namespaces LXC + micro-VMs Firecracker. Séparation au niveau kernel.
Firewall au niveau host
Règles ingress + egress appliquées sur l'host, pas dans le container. Inviolable.
Permissions proxy
Groupes d'auth JWT / Mot de passe / IP / Token superposés aux URLs.
Ségrégation de realms
Isolation tenant au niveau API. Tokens scopés à des realms spécifiques.
Chiffrement disque
AES-256 au repos. Swap chiffré. Boot déverrouillé à distance.
Tout est une requête HTTP inspectable.
Audit trails unifiés. Chaque action contre un conteneur est une entrée de log proxy. N'importe quel service peut être MITM via hoody-exec ou hoody-curl pour ajouter des contrôles de sécurité AI, du logging, ou du rate limiting sans modifier le service.
Logs d'audit unifiés
Les logs proxy couvrent chaque service. Query, export (NDJSON), agrégation de stats — tout via l'API logs de /platform/proxy.
MITM par design
Insère du middleware entre n'importe quel service et ses clients. Utilisé pour les portes de sécurité AI, le logging conformité, le rate limiting — pas de changement de service requis.
Fork de plateforme
Chaque utilisateur peut MITM l'API Hoody elle-même pour customiser le comportement de la plateforme — sans forker la codebase.
Suspicion de compromission ? Supprimez le container.
Chaque URL de conteneur meurt à l'instant où le conteneur est supprimé. Pas de propagation DNS. Pas d'invalidation de cache. Pas de token périmé à rotater. L'URL était la surface ; supprimer le conteneur retire la surface entièrement.
DELETE /api/v1/containers/ID
Un appel API. Authentifié avec votre JWT ou votre token control-plane.
L'URL arrête de router
Le proxy retire l'entrée de routage. Le hostname renvoie 404 immédiatement — pas 60 secondes plus tard.
Re-spawn en quelques minutes
Créez un nouveau conteneur avec un nouvel ID. Nouvelle URL. L'ancienne URL est morte à jamais. Pas de credentials résiduels à rotater.
Densité et isolation ne sont pas des compromis ici.
Bare-metal. Kernel durci. Disque chiffré. Défense à six couches. Chaque propriété est déjà vraie sur votre premier container.
Voir aussi — /platform/proxy pour les permissions URL et groupes d'auth, /platform/control-plane pour la gestion realm/token, /methods/access-network pour firewall + egress.