Gérer les secrets et credentials dans une infrastructure auto-hébergée : Vault, SOPS et bonnes pratiques

Quand on auto-héberge une stack open source — base de données, reverse proxy, SSO, CI/CD — on accumule rapidement des dizaines de secrets : mots de passe, clés API, tokens OAuth, certificats TLS. Les stocker en clair dans des fichiers .env ou des dépôts Git est un risque majeur. Cet article présente les outils et méthodes pour gérer ces secrets de manière sécurisée, auditable et automatisée.

Le problème : des secrets partout, mal protégés

Dans une infrastructure typique auto-hébergée, on retrouve des credentials à chaque couche : le mot de passe PostgreSQL dans un docker-compose.yml, la clé SMTP dans la configuration Nextcloud, le secret client Keycloak dans un fichier de déploiement. Trop souvent, ces valeurs finissent commitées dans un dépôt Git, partagées par messagerie, ou dupliquées sur plusieurs serveurs sans contrôle de version.

Les conséquences sont connues : fuites accidentelles, difficulté à effectuer une rotation de credentials, impossibilité de savoir qui a accédé à quel secret et quand. Pour une infrastructure en production, même modeste, c’est un angle mort de sécurité qu’il faut adresser.

SOPS : chiffrer les secrets dans Git

SOPS (Secrets OPerationS), développé par Mozilla puis maintenu par la CNCF, permet de chiffrer des fichiers YAML, JSON ou .env tout en gardant les clés lisibles. Seules les valeurs sont chiffrées. Cela signifie qu’on peut versionner les fichiers de secrets dans Git en toute sécurité : le diff reste lisible (on voit quelles clés ont changé), mais les valeurs restent protégées.

SOPS supporte plusieurs backends de chiffrement : age (simple, moderne, sans dépendance externe), PGP, ou des KMS cloud (AWS KMS, GCP KMS, Azure Key Vault). Pour une infrastructure auto-hébergée, le couple SOPS + age est le plus adapté : léger, sans service tiers, et facile à intégrer dans un pipeline CI/CD.

Un workflow typique avec SOPS :

Créer un fichier secrets.yaml avec les valeurs en clair
Chiffrer avec sops --encrypt --age <clé_publique> secrets.yaml > secrets.enc.yaml
Commiter secrets.enc.yaml dans le dépôt Git
Au déploiement, déchiffrer à la volée avec sops --decrypt secrets.enc.yaml

HashiCorp Vault : un coffre-fort centralisé

Pour les infrastructures plus complexes ou les équipes de plusieurs personnes, HashiCorp Vault apporte un niveau supplémentaire. Vault est un serveur dédié à la gestion des secrets : il stocke, génère, révoque et audite l’accès aux credentials de manière centralisée.

Les avantages clés de Vault pour une infrastructure auto-hébergée :

Secrets dynamiques : Vault peut générer des credentials PostgreSQL à la demande avec une durée de vie limitée (lease). Fini les mots de passe partagés qui ne changent jamais.
Rotation automatique : les secrets expirent et sont renouvelés sans intervention manuelle.
Audit complet : chaque lecture ou écriture de secret est journalisée. On sait exactement qui a accédé à quoi et quand.
Politiques d’accès : chaque application ou utilisateur n’accède qu’aux secrets dont il a besoin, selon le principe du moindre privilège.

Vault peut être déployé en conteneur Docker et s’intègre nativement avec Kubernetes, Ansible, et la plupart des outils d’infrastructure. Pour un démarrage simple, le backend de stockage fichier suffit ; pour la production, un backend Consul ou Raft est recommandé.

Choisir la bonne approche selon son contexte

Le choix entre SOPS et Vault n’est pas binaire. Les deux outils répondent à des besoins différents et peuvent coexister :

Infrastructure solo, quelques services : SOPS + age suffit largement. Les secrets sont versionnés, chiffrés, et le workflow reste simple.
Équipe de plusieurs personnes, secrets partagés : Vault apporte le contrôle d’accès, l’audit et la rotation automatique qui deviennent nécessaires.
Environnement mixte (CI/CD + déploiement) : SOPS pour les secrets de configuration versionnés, Vault pour les credentials dynamiques générés au runtime.

Bonnes pratiques essentielles

Quel que soit l’outil choisi, certaines pratiques sont universelles pour la gestion des secrets :

Ne jamais commiter de secrets en clair. Configurer un hook pre-commit (avec gitleaks ou detect-secrets) pour bloquer automatiquement les commits contenant des credentials.
Rotation régulière. Même avec un coffre-fort, un secret qui ne change jamais est un secret vulnérable. Planifier des rotations trimestrielles au minimum.
Séparer les environnements. Les secrets de développement, staging et production doivent être strictement isolés. Jamais de secret de production dans un .env.example.
Principe du moindre privilège. Chaque service n’accède qu’aux secrets dont il a strictement besoin. Un service web n’a pas besoin du mot de passe root de la base de données.
Documenter le schéma de secrets. Maintenir un fichier listant les secrets nécessaires (sans les valeurs) pour faciliter l’onboarding et les audits.

Intégration avec Ansible et CI/CD

Si vous utilisez déjà Ansible pour la gestion de votre infrastructure, Ansible Vault (à ne pas confondre avec HashiCorp Vault) offre un chiffrement intégré des variables sensibles dans les playbooks. C’est une solution pragmatique pour les petites infrastructures déjà outillées avec Ansible.

Dans un pipeline CI/CD (Gitea Actions, par exemple), les secrets peuvent être injectés via les variables de repository chiffrées, puis déchiffrés à la volée pendant le déploiement via SOPS ou récupérés depuis Vault via son API HTTP. L’important est que les secrets ne transitent jamais en clair dans les logs du pipeline — pensez à masquer les sorties sensibles.

Conclusion

La gestion des secrets est souvent le maillon faible d’une infrastructure auto-hébergée. Pourtant, les outils open source disponibles — SOPS, age, HashiCorp Vault, Ansible Vault — sont matures et bien documentés. L’investissement initial est modeste comparé au risque d’une fuite de credentials. Commencez par SOPS + age pour versionner vos secrets existants, puis évaluez Vault si votre infrastructure ou votre équipe grandit. Le plus important est de ne jamais laisser un secret en clair dans un dépôt ou un fichier de configuration non protégé.