Après avoir couvert sops et age pour le chiffrement de secrets versionnés dans un dépôt, l’agence a fait évoluer sa pratique sur une partie des projets vers une approche différente : ne plus versionner de secret chiffré du tout, mais récupérer chaque identifiant à la volée depuis un coffre-fort d’équipe au moment précis où un pipeline en a besoin. 1Password, déjà utilisé en interne pour la gestion des mots de passe, propose une CLI et un « Service Account » qui rendent cette approche simple à mettre en œuvre.
La différence avec sops et age n’est pas anodine : sops chiffre un fichier destiné à être versionné, ce qui suppose de gérer des clés de déchiffrement quelque part. L’approche par CLI 1Password élimine complètement le fichier de secrets du dépôt : seule une référence symbolique au secret y figure, sa valeur réelle restant exclusivement dans le coffre-fort.
Créer un compte de service à portée limitée
1Password permet de générer un jeton de « compte de service », un identifiant d’API dédié à l’automatisation, dont l’accès peut être restreint à un ou plusieurs coffres précis, jamais à l’intégralité du compte de l’équipe. Pour un pipeline de déploiement, un coffre dédié nommé deploiement-production ne contient que les secrets nécessaires à cet usage, isolés des mots de passe personnels des collaborateurs.
Référencer un secret plutôt que le stocker
Une fois le secret créé dans 1Password, avec un nom d’élément clair comme boutique-nord-db-production, un fichier de configuration versionné dans le dépôt ne contient qu’une référence à cet élément, jamais sa valeur :
# .env.production (versionné, sans danger)
DB_HOST=op://deploiement-production/boutique-nord-db-production/host
DB_NAME=op://deploiement-production/boutique-nord-db-production/database
DB_USER=op://deploiement-production/boutique-nord-db-production/username
DB_PASSWORD=op://deploiement-production/boutique-nord-db-production/password
Ce format d’URI, propre à 1Password, désigne le coffre, l’élément, puis le champ précis à l’intérieur de cet élément. Un fichier .env qui ne contient que ce genre de références peut être committé sans crainte : sa lecture seule ne révèle rien d’exploitable sans accès au coffre lui-même.
Injecter les secrets réels au moment du déploiement
La commande op run lit un fichier contenant des références, résout chacune d’elles en interrogeant l’API 1Password, et exécute la commande qui suit avec les variables d’environnement remplacées par leurs vraies valeurs, sans jamais écrire ces valeurs sur disque :
op run --env-file=".env.production" -- wp db import backup.sql --allow-root
Dans un pipeline GitHub Actions, cela donne :
- name: Installer la CLI 1Password
uses: 1password/install-cli-action@v1
- name: Déployer avec secrets injectés
env:
OP_SERVICE_ACCOUNT_TOKEN: ${{ secrets.OP_SERVICE_ACCOUNT_TOKEN }}
run: |
op run --env-file=".env.production" -- \
./scripts/deploiement.sh
Le seul secret qui transite encore par les secrets GitHub Actions classiques est le jeton du compte de service lui-même, OP_SERVICE_ACCOUNT_TOKEN. Ce jeton ne donne accès qu’au coffre deploiement-production, et peut être révoqué instantanément depuis la console 1Password en cas de compromission, sans avoir à faire tourner tous les secrets qu’il protège.
Utilisation directe dans un script shell
Pour un script de déploiement qui a besoin d’un secret ponctuel sans passer par un fichier .env complet, la commande op read récupère une valeur unique :
MOT_DE_PASSE_DB=$(op read "op://deploiement-production/boutique-nord-db-production/password")
Rotation d’un identifiant sans toucher au code
L’un des bénéfices concrets de cette approche est apparu lors d’un incident de sécurité chez un client, où un mot de passe de base de données devait être changé en urgence. Avec l’ancienne approche par fichier chiffré, l’opération demandait de régénérer le fichier, de le rechiffrer, et de le committer à nouveau. Avec la référence 1Password, il a suffi de changer la valeur du champ password directement dans le coffre : tous les pipelines qui la référencent ont récupéré la nouvelle valeur dès leur prochaine exécution, sans aucune modification de code ni nouveau déploiement du dépôt lui-même.
Limites à connaître
- Cette approche introduit une dépendance réseau à l’API 1Password au moment du déploiement : une panne de leur service bloque le déploiement, un scénario à anticiper dans la fenêtre de tolérance du client.
- Elle ne convient pas à un environnement totalement air-gapped, sans accès sortant à Internet, un cas rare mais qui existe sur certains projets sensibles de l’agence.
- Le coût de la licence 1Password Teams ou Business doit être budgété, contrairement à sops et age qui restent gratuits.
Le meilleur secret n’est pas celui qu’on chiffre le mieux, c’est celui qui n’existe jamais en clair là où quelqu’un pourrait le trouver par accident.
En résumé
Depuis la bascule vers cette approche sur les projets qui le justifient, aucun secret en clair n’a été retrouvé dans un dépôt de l’agence, un progrès net par rapport à l’époque où un fichier .env.example mal renommé finissait parfois par contenir de vraies valeurs. Cette méthode ne remplace pas sops et age partout : sur des projets sans compte 1Password d’équipe déjà en place, l’approche par chiffrement de fichier reste plus simple à démarrer.
