Format Atlas

Guides

Où stocker les paramètres et les secrets

Séparez les paramètres ordinaires des identifiants, puis choisissez leur emplacement pour le développement local, la CI et la production selon les besoins d’accès.

Quel format choisir ?

Choisissez selon le rôle de chaque fichier dans votre flux de travail.

  • Valeurs par défaut à partager → Versionnez des exemples sans secrets
  • Paramètres locaux de chaque développeur → Utilisez .env si l’outil le permet et excluez-le de Git
  • Identifiants de CI → Utilisez le gestionnaire de secrets du fournisseur et limitez les accès
  • Production et conteneurs → Utilisez la fonction de gestion des secrets de la plateforme et n’accordez que les accès nécessaires
  • Fuite possible → Révoquez ou renouvelez l’identifiant ; supprimer le fichier ne suffit pas

Distinguer paramètres et secrets

Traitez différemment les paramètres non sensibles, comme les URL de services ou les indicateurs de fonctionnalité, et les identifiants tels que les mots de passe, clés d’API et clés privées. N’intégrez pas de vrais identifiants au code et ne validez pas de fichiers qui en contiennent dans un dépôt partagé. Vérifiez d’abord les mécanismes de configuration acceptés par l’application.

Exclure les fichiers .env locaux de Git

Si vos outils le permettent, placez les valeurs propres à chaque développeur dans un fichier .env local et partagez un .env.example contenant uniquement les noms de variables et des valeurs fictives. Ajoutez le vrai fichier .env à .gitignore et vérifiez qu’il n’est pas déjà suivi par Git. Une règle d’exclusion n’est pas un coffre-fort et ne supprime pas les valeurs déjà présentes dans l’historique.

Utiliser le gestionnaire de secrets de la CI avec des droits minimaux

Dans un système de CI comme GitHub Actions, enregistrez les identifiants au moyen de la fonction de gestion des secrets du fournisseur, et non dans les fichiers de workflow. Limitez l’accès aux dépôts, environnements et tâches qui en ont besoin, accordez aux jetons uniquement les permissions nécessaires et évitez d’afficher les valeurs. Le masquage des journaux ne garantit pas que toutes les valeurs transformées ou sorties de commande seront cachées.

Fournir les secrets depuis l’environnement de production

En production, privilégiez le gestionnaire de secrets de l’hébergeur ou du fournisseur cloud, et limitez les déploiements et services autorisés à lire chaque valeur. Docker Compose peut monter des secrets sous forme de fichiers pour les services explicitement autorisés ; les fonctions et limites varient selon la plateforme. Consultez la documentation de l’environnement réellement utilisé. Si la plateforme le permet, envisagez des identifiants de courte durée comme OIDC plutôt que des clés à longue durée de vie.

Révoquer ou renouveler les identifiants exposés

Si un secret a pu apparaître dans un commit, un journal de CI ou une conversation, supprimer la copie visible ne suffit pas. Révoquez ou renouvelez d’abord la clé ou le jeton concerné, puis examinez les journaux d’accès et les utilisations possibles. Traitez ensuite l’historique du dépôt et les journaux selon le besoin, et renforcez les contrôles d’accès pour éviter que cela se reproduise.

Formats à envisager

.env

Adapté pour: Charger des valeurs locales avec les outils compatibles avec les fichiers .env

Moins adapté pour: Partager ou stocker des secrets sans protection

.gitignore

Adapté pour: Éviter l’ajout accidentel de fichiers .env locaux non suivis

Moins adapté pour: Révoquer des secrets ou effacer de l’historique des valeurs déjà suivies par Git

Avant l’export

  • .env et .gitignore ne suffisent pas à protéger les secrets ; vérifiez le suivi Git, les journaux de CI, les sauvegardes et le gestionnaire de secrets de l’environnement d’exécution.
  • Le masquage peut laisser visibles des valeurs transformées ou certaines sorties de commande.
  • En cas de fuite suspectée, révoquez ou renouvelez l’identifiant au lieu de simplement supprimer le fichier.

Guides

Choisir un format de configurationVérifiez d'abord les formats acceptés par l'outil. S'il y a plusieurs choix, retenez celui que l'équipe peut valider et maintenir sans risque.Choisir un format de certificat ou de cléVérifiez d'abord le format exigé par la destination et distinguez certificat émis, demande de certificat et clé privée.

Références et spécifications