Un nouveau développeur arrive, ou un prestataire commence sa mission, et la première chose dont il a besoin est le .env qui fait tourner le projet. Ce fichier mélange en général des réglages anodins et les valeurs les plus sensibles que possède l’équipe, et c’est pour cela qu’il finit si souvent dans un message privé ou en pièce jointe d’un e-mail intitulé « config ».
Pour transmettre un fichier de configuration à un développeur en toute sécurité, traitez-le comme deux choses distinctes : les réglages, qui peuvent circuler par n’importe quel canal, et les secrets, qui circulent une seule fois par un canal qui ne garde aucune copie. Ce guide explique comment séparer les deux, comment envoyer la partie secrète et quoi dire au développeur pour que le fichier reste protégé une fois arrivé.
Lisez le fichier comme si chaque ligne était publique
Ouvrez le fichier et rangez chaque ligne dans l’un de ces deux groupes.
- Réglages : niveaux de log, ports, feature flags, endpoints hors production, identifiants client publics. Leur place est dans le dépôt, sous forme de fichier d’exemple, et vous pouvez les envoyer comme bon vous semble.
- Secrets : mots de passe de base de données, clés API, secrets de signature, clés privées, secrets client OAuth, tout ce qui donne un accès. Recherchez
PASSWORD,SECRET,TOKEN,KEYetPRIVATE, puis lisez le reste, car une chaîne de connexion qui contient le mot de passe ne se signale pas d’elle-même.
Demandez-vous ensuite ce que fait le développeur. Le développement local branché sur l’environnement de préproduction a besoin des valeurs de préproduction. Il n’a pas besoin des clés de production, ni de la clé live du prestataire de paiement simplement parce que le fichier en contient une.
Gardez les secrets hors du fichier versionné
Le fichier .env.example versionné documente chaque variable avec une valeur fictive. Les vraies valeurs sont injectées à l’exécution depuis l’environnement, un gestionnaire de secrets ou le stockage de secrets de la plateforme elle-même. Avec ce modèle, le fichier que vous transmettez ne contient que les valeurs secrètes, et la copie locale du développeur est le seul endroit où elles se trouvent toutes ensemble.
# .env.example (committed)
DATABASE_URL=postgres://app:CHANGE_ME@staging-db.internal:5432/app
STRIPE_SECRET_KEY=sk_test_CHANGE_ME
SESSION_SECRET=CHANGE_ME
LOG_LEVEL=debug
Ajoutez .env au .gitignore avant que quiconque en ait un vrai, et envisagez un hook pre-commit comme gitleaks pour qu’un commit malencontreux échoue tout de suite.
Donnez au développeur ses propres identifiants quand c’est possible
Une transmission est aussi l’occasion d’arrêter de partager. Si la base de données gère des utilisateurs individuels, créez-en un pour le développeur, avec les droits dont son travail a besoin et une date d’expiration. Si l’API propose des clés restreintes, émettez-en une à son nom. Le guide sur les accès temporaires à une base de données pour un prestataire décrit cette méthode. Des identifiants créés pour une personne peuvent être retirés à cette seule personne.
Comment transmettre les valeurs secrètes
Deux méthodes fonctionnent, et aucune ne laisse le fichier dans un message.
Collez les lignes secrètes dans un lien à usage unique. Ouvrez l’outil de lien secret, collez uniquement les lignes qui contiennent des secrets et créez le lien. Le texte est chiffré dans votre navigateur avant d’être stocké, la copie stockée est détruite dès la première ouverture du lien, et le lien expire au bout d’une heure, de 24 heures ou de sept jours si personne ne l’ouvre. Jusqu’à 10 000 caractères passent sans compte, soit plusieurs fois la taille de la plupart des fichiers .env.
Joignez le fichier entier à un lien secret. Depuis un compte LinkPilot connecté, vous pouvez joindre à un secret jusqu’à trois fichiers de 9 Mo chacun. Chaque fichier est chiffré dans votre navigateur avec une clé dérivée de la clé du secret lui-même : le serveur ne détient jamais le fichier en clair, et la pièce jointe est supprimée après l’unique téléchargement. C’est la meilleure méthode quand le fichier doit arriver octet pour octet, par exemple un fichier JSON de compte de service ou un keystore.
Dans les deux cas :
- Vérifiez l’identité du développeur par le canal du recrutement ou du contrat, et non par l’adresse qui a demandé le fichier.
- Réglez l’expiration sur la période où il s’en servira réellement. Une heure s’il attend, une journée s’il est dans un autre fuseau horaire.
- Limitez le nombre d’ouvertures à une seule.
- Ajoutez une phrase de passe avec un compte Pro pour les valeurs de production, et envoyez-la par un autre canal.
- Envoyez le lien avec une note d’une ligne qui dit ce qu’il contient et où va le fichier. Envoyez les réglages non secrets séparément ou indiquez le fichier d’exemple dans le dépôt.
Une invitation dans le coffre-fort est la meilleure méthode quand le développeur est embauché en poste fixe et que votre équipe utilise déjà un gestionnaire de secrets avec des accès par développeur. Utilisez le lien à usage unique en attendant que cela soit en place, et pour toute personne qui n’aura jamais accès au coffre-fort.
Dites au développeur où ranger le fichier
Une transmission propre peut encore mal finir si le fichier atterrit dans un dossier partagé. Envoyez ces consignes avec les informations de connexion :
- Enregistrez-le sous le nom
.envà la racine du projet, et nulle part ailleurs. Vérifiez qu’il est couvert par le.gitignoreavant le premier commit. - Ne collez pas les valeurs dans un ticket ou une messagerie pour demander si elles sont correctes. Signalez une variable manquante ou invalide uniquement par son nom, et l’expéditeur émettra une nouvelle valeur.
- Renouvellement au départ. À la fin de la mission, les valeurs de ce fichier sont renouvelées. Annoncez-le dès le début, pour que personne ne soit surpris.
Faites confirmer, puis faites le ménage
Demandez au développeur de confirmer le nom du fichier, l’environnement et un repère non secret, par exemple un commentaire de version sur la première ligne. Si un lien à usage unique indique qu’il a été ouvert avant que le développeur n’y accède, considérez toutes les valeurs qu’il contenait comme exposées et renouvelez-les.
Une fois la transmission terminée, révoquez tout lien qui n’a jamais été ouvert, supprimez toute copie temporaire que vous avez stockée et notez qui a reçu les valeurs de quel environnement, et quand. Cette trace constitue la piste d’audit. Le fichier lui-même ne doit exister que sur la machine qui en a besoin.