Votre plateforme de services tourne en Podman rootless, et il vous faut bien un point d’entrée public pour terminer TLS et gérer ACME. La question est de savoir où le mettre. Je fais le choix de garder Caddy hors Podman, comme service hôte installé depuis le dépôt APT officiel signé de Caddy.

Caddy dans Podman ?

Non. La frontière est simple : scripts/deploy.sh tourne rootless en tant que podman, et il ne doit jamais acquérir d’autorité root sur un service TLS public. Si Caddy vivait dans Podman, le déploiement applicatif rootless pourrait, par construction, réécrire la configuration du point d’entrée public. C’est exactement la confusion de privilège que je veux éviter.

Caddy reste donc hors Podman, hors deploy.sh, et la procédure de changement est un runbook administrateur explicite, pas une interface du repo. Le repo ne peut pas établir la provenance d’un paquet hôte, publier un Caddyfile root, ou reloader un service hôte depuis sa commande de déploiement rootless. L’administrateur est l’autorité d’exécution pour ce changement.

Quel paquet Caddy installer ?

Le paquet Caddy de Debian 13 stable est en 2.6.2. L’amont est en 2.11.4. 5 versions mineures de retard sur un service qui termine TLS et gère ACME, c’est trop : les correctifs amont arrivent tard, et ACME continue d’évoluer.

Les backports (2.11.2) améliorent la fraîcheur tout en gardant le packaging Debian, mais laguent encore. Je les garde comme fallback explicite, pas comme défaut.

Le téléchargement de binaire manuel affaiblit la provenance, la cohérence des mises à jour, l’intégration systemd, le rollback et l’inventaire par rapport à un paquet APT signé.

J’ai donc choisi d’utiliser le dépôt APT officiel de Caddy, canal stable uniquement, avec vérification indépendante de l’empreinte de la clé de signature avant confiance. Jamais testing, jamais unstable, jamais un binaire non vérifié.

Automatiser la procédure ?

La proposition initiale était ambitieuse : un wrapper root séparé, un harness local, des schémas d’évidence, un cycle de vie de corrélation, une gate de mutation testing, et un codebase root séparé. Tout ça pour franchir la frontière rootless vers root de façon auditée.

Je l’ai rejetée comme disproportionnée pour la phase actuelle. Les prérequis host ne sont pas disponibles, il n’y a pas encore d’évidence runtime réelle à corréler, et le coût d’implémentation et de maintenance d’un système d’enforcement automatisé n’apportait rien de concret maintenant. Le runbook administrateur est l’alternative KISS délibérée : procédurale, documentée, pas automatisée.

Ce n’est pas une promesse d’implémenter ces contrôles plus tard. C’est une réduction de scope assumée.

Ce que le runbook impose

Avant tout changement, j’approuve explicitement 2 choses : le commit exact du repo contenant le Caddyfile, et la version exacte du paquet Caddy avec sa source. Ensuite, étape par étape, en stoppant au premier échec :

  1. Vérifier le Caddyfile approuvé depuis le checkout canonique, sans jamais runner le checkout en root.
  2. Confirmer l’origine APT, l’empreinte de clé, l’architecture et la version exacte.
  3. S’assurer que /etc/caddy/Caddyfile est un fichier régulier (pas un symlink), backup horodaté.
  4. Stager le candidat en root:caddy 0640, valider avec caddy validate.
  5. Publication atomique si possible (rename sur même filesystem), jamais d’écriture aveugle à travers un symlink.
  6. Re-valider le fichier publié, puis systemctl reload caddy : reload, jamais restart implicite.
  7. Valider le runtime séparément : état du service, listeners :80/:443, DNS/TLS, proxy public, santé applicative.

Les upgrades non assistés ne doivent pas reloader Caddy implicitement. Le paquet et la config précédents restent disponibles pour un rollback explicite. Une validation échouée empêche la publication. Un check runtime échoué est rapporté comme échec, jamais converti silencieusement en succès.

Ce que ça ne prouve pas

Le runbook est procédural, pas un enforcement automatisé. Sa sortie de commande n’est pas une revendication que le host ou le runtime public a été validé. Tant que l’administrateur n’a pas exécuté la procédure et capturé une évidence acceptable, le statut runtime reste BLOCKED. Les checks runtime ne transforment pas l’inspection statique en évidence runtime.

Ce que j’en retiens

La frontière host/rootless n’est pas négociable, mais l’enforcement, si. Un runbook documenté, exécuté par un humain qui révise chaque commande privilégiée, vaut mieux qu’un système automatisé prématuré dont les prérequis n’existent pas encore.