Images durcies

Huit images de conteneurs construites FROM scratch : aucun système d'exploitation, aucun shell, aucun gestionnaire de paquets. Seuls le binaire du service et ses dépendances réelles entrent dans l'image finale.

Le parc

bind9        DNS autoritatif et résolveur à vues
squid        Proxy transparent, SSL bump
c-icap       Passerelle ICAP entre le proxy et l'antivirus
clamav       Antivirus, signatures vérifiées à la construction
suricata     IPS en coupure, NFQUEUE
nginx-waf    ModSecurity et OWASP Core Rule Set
php-fpm      WordPress, extensions compilées
varnish      Cache HTTP, VCL compilée à chaud

Principes

• Compilé depuis les sources : le service exposé n'est jamais un paquet de distribution. Sources vérifiées par signature GPG quand l'amont en publie une, sinon par une empreinte épinglée.
• Clôture des dépendances : les bibliothèques copiées dans l'image sont celles que les binaires ouvrent réellement, résolues à la construction. Jamais /lib ni /usr/lib en bloc.
• Non-root, sans privilège accordé au conteneur : chaque image tourne sous un UID explicite. Les deux seuls privilèges réseau du parc sont posés sur le binaire, pas donnés au conteneur.
• Un seul tag épinglable : chaque image publie latest, la version amont seule — toutes deux réécrites à chaque reconstruction — et la version suffixée d'un compteur de révision. Seule la dernière désigne toujours la même image.
• Six portes de CI : lint, tests unitaires, tests fonctionnels sur l'image construite, inventaire de son contenu, contrôle de clôture, et analyse des paquets avant qu'ils n'entrent dans l'image.

Ce que ça donne

Une seule bibliothèque est commune aux huit images : le chargeur musl. Aucun bit setuid, aucun fichier inscriptible par tous. Et dans chaque image, ce qui pèse le plus n'est pas le service mais les données inertes qu'il traîne — fuseaux horaires et magasin de certificats.

Articles détaillés

Chaque image fait l'objet d'un article technique complet dans la catégorie Images Hardened.