Variables d’environnement et secrets sur Dockup

Les variables d’environnement et les secrets relient le code de l’application à la configuration de production, mais leurs exigences en matière de divulgation et de cycle de vie diffèrent. L’URL de base d’une API publique peut être affichée sans risque dans les logs ; ce n’est pas le cas d’un mot de passe de base de données ou d’une clé de signature. Dockup représente explicitement cette distinction et masque les valeurs secrètes stockées dans les sorties de lecture.

Les modifications de configuration nécessitent également un redéploiement. Définir une nouvelle valeur met à jour la configuration souhaitée du service, mais le processus déjà en cours d’exécution conserve l’environnement qu’il a reçu au démarrage.

Quelle est la différence entre une variable et un secret ?

Les deux valeurs sont transmises au processus de l’application sous forme de données d’environnement, mais leur traitement opérationnel diffère.

Type	Exemple	Peut apparaître dans une sortie de lecture ?	Traitement recommandé
Variable standard	NODE_ENV=production	Oui	Configuration vérifiable
Variable standard	PUBLIC_API_URL=https://...	Oui	Peut figurer dans dockup.yaml
Secret	DATABASE_URL=postgres://...	Aucune valeur stockée	Commande de secret ou store CI
Secret	JWT_SIGNING_KEY=...	Aucune valeur stockée	Effectuer une rotation et restreindre l’accès
Secret	DOCKUP_TOKEN=...	Ne jamais le stocker comme configuration de l’application sauf nécessité	Authentification au niveau du processus

Marquez une valeur comme secrète si sa divulgation permettrait un accès, une usurpation d’identité, un déchiffrement, une signature ou un déplacement latéral. Le fait que « le frontend la contienne déjà » indique que la valeur relève de la configuration publique et non d’un secret.

Ne placez pas de secrets dans le contrôle de version, dockup.yaml, les exemples de sortie, les captures d’écran, les prompts d’agents ou les descriptions d’issues. Un placeholder masqué est plus sûr qu’un token réaliste, car les exemples copiés ont tendance à devenir des pratiques de production.

Comment définir et inspecter la configuration de l’environnement ?

Listez les clés actuelles pour une cible précise :

dockup env list -s production/api --json

La réponse inclut chaque clé, indique s’il s’agit d’un secret et n’affiche la valeur que lorsqu’elle n’est pas protégée.

Définissez une variable standard :

dockup env set NODE_ENV=production \
  -s production/api \
  --json

Définissez un secret à partir de l’environnement du shell actuel :

dockup env set DATABASE_URL="$DATABASE_URL" \
  --secret \
  -s production/api \
  --json

Supprimez une valeur obsolète :

dockup env remove OLD_FEATURE_FLAG \
  -s production/api \
  --json

Importez en masse un fichier de type .env :

dockup env import .env.production \
  -s production/api \
  --json

Utilisez --secret lors de l’import uniquement si toutes les valeurs importées doivent être traitées comme des secrets. Les fichiers mixtes sont plus difficiles à examiner et encouragent souvent à classer à tort des configurations inoffensives comme des secrets, ou à ne pas classer des identifiants comme tels. Séparez-les lorsque c’est possible.

La syntaxe exacte des commandes est maintenue dans la référence de la CLI Dockup.

Pourquoi un redéploiement est-il nécessaire après une modification de configuration ?

Les variables d’environnement sont lues au démarrage d’un processus. La mise à jour de la configuration de la plateforme ne modifie pas la mémoire d’un processus Node.js, Python, Go ou autre déjà en cours d’exécution. Le service doit démarrer un nouveau container avec le nouvel environnement.

La séquence correcte est la suivante :

dockup env set FEATURE_FLAG=on \
  -s production/api \
  --json

dockup deploy production/api --wait --json

--wait rend la deuxième étape vérifiable. Le délai d’attente par défaut est de 900 secondes, le code de sortie 0 indique une réussite et les échecs renvoient un code différent de zéro accompagné de codes structurés.

Le processus blue-green sans interruption de Dockup démarre la nouvelle version, applique le health gate, puis achemine le trafic vers celle-ci. Cela évite de redémarrer sur place le container actuel avec une configuration qui n’a pas été vérifiée.

Si une rotation de secret modifie à la fois le producteur et le consommateur, planifiez la compatibilité. Faire tourner un mot de passe de base de données avant que l’application ne reçoive la nouvelle valeur peut provoquer une interruption de service. Utilisez une période de chevauchement, la prise en charge de deux clés ou une modification ordonnée lorsque le système externe le permet.

Les mécanismes de déploiement sont expliqués dans les déploiements sans interruption.

Comment le masquage des secrets réduit-il les risques liés aux agents ?

Les agents de code résument fréquemment la sortie des commandes. Un outil qui renvoie des secrets stockés transforme une demande anodine du type « afficher la configuration actuelle » en exposition d’identifiants.

Dockup masque les valeurs secrètes. L’agent peut voir que DATABASE_URL existe et est marqué comme secret, mais il ne peut pas lire la chaîne de connexion stockée. Il peut remplacer la valeur lorsque l’utilisateur lui en fournit une nouvelle via un environnement sécurisé.

Cela permet d’utiliser une instruction plus sûre :

Confirmez que les clés secrètes requises existent, mais n’affichez jamais leurs valeurs. Si une valeur doit être modifiée, lisez-la uniquement depuis l’environnement du processus et renvoyez le nom de la clé, pas le secret.

Le masquage des secrets doit également s’appliquer aux diagnostics. Évitez :

printenv

dans un transcript d’agent, même si la commande PRO exec peut exécuter des commandes ponctuelles dans un container. Préférez un contrôle ciblé de l’application qui indique la présence, une catégorie de longueur ou la réussite de la connexion sans divulguer la valeur.

Le guide garde-fous de production pour les agents IA couvre conjointement les limites des prompts et des outils.

Comment faire tourner et auditer les secrets ?

La rotation est une modification de production contrôlée, pas une simple modification de texte. Suivez cette séquence :

1. Créez ou obtenez le nouvel identifiant dans le système qui en est responsable.
2. Stockez-le dans l’environnement CI ou opérateur approuvé.
3. Définissez le nouveau secret dans Dockup sans l’afficher.
4. Déployez avec --wait.
5. Vérifiez l’état de santé et le comportement de l’application.
6. Révoquez l’ancien identifiant une fois la nouvelle version active.
7. Consultez le journal d’audit Dockup.
8. Notez la date et le responsable de la rotation sans enregistrer la valeur.

dockup audit --writes --json

Les éléments d’audit doivent montrer que la configuration a changé et qu’un déploiement a suivi. Ils ne doivent pas contenir la valeur secrète.

Pour les identifiants de base de données, tenez compte des pools de connexions. Les connexions existantes peuvent rester authentifiées après la rotation, tandis que les nouvelles connexions utilisent le nouveau mot de passe. La vérification doit inclure une nouvelle connexion, et pas uniquement des requêtes servies par un ancien pool.

Pour les clés d’API soumises à des permissions, capturez la valeur générée de manière sécurisée lors de sa création. Stockez-la immédiatement dans le système de secrets approuvé, limitez-la aux permissions nécessaires et faites-la tourner sans la reproduire dans la sortie du déploiement.

Quelle politique de configuration permet d’éviter la dérive ?

Définissez quelles valeurs appartiennent à chaque source :

Source	Contenu approprié
Code du repository	Valeurs par défaut qui ne dépendent pas de l’environnement
dockup.yaml	Configuration de déploiement standard et vérifiable
Variables secrètes Dockup	Identifiants d’exécution
Secret store CI	Token de déploiement et valeurs injectées pour la rotation
Sortie de la base de données managée	Données de connexion transmises au service consommateur
.env local	Valeurs réservées au développement, exclues de Git

L’application de dockup.yaml est additive par défaut. Les valeurs d’environnement standard absentes du fichier restent présentes jusqu’à l’utilisation explicite de --prune, et les secrets ne sont jamais supprimés par ce biais. Consultez dockup.yaml comme code de configuration avant d’adopter le nettoyage par manifest.

Utilisez des noms de clés cohérents entre les environnements, mais ne partez pas du principe que les valeurs sont interchangeables. Une clé de staging ne doit pas donner accès à la production. Les déploiements de preview dans un projet utilisant un réseau privé reçoivent automatiquement un utilisateur de base de données en lecture seule pour accéder aux données de production ; ils ne doivent pas hériter par défaut d’identifiants en écriture.

Réagir à la fuite d’un secret

Si un secret apparaît dans un transcript, un log, un commit ou une capture d’écran, le masquer ultérieurement ne suffit pas. Considérez-le comme compromis :

1. Révoquez-le ou faites-le tourner dans le système source.
2. Mettez à jour le secret Dockup.
3. Redéployez et vérifiez.
4. Supprimez les éléments exposés lorsque c’est possible.
5. Recherchez toute utilisation abusive dans les journaux d’audit et d’accès.
6. Documentez la cause et la mesure de prévention adoptée.

La réécriture de l’historique Git peut limiter les découvertes futures, mais elle ne permet pas de prouver qu’un identifiant copié a disparu. La révocation est l’action décisive.

Checklist de vérification de l’environnement

Avant chaque release de production, vérifiez que les clés requises existent, que les clés secrètes sont marquées comme telles, qu’aucun secret n’est commité, que les valeurs standard correspondent à l’environnement prévu et qu’un redéploiement fait partie de la modification. Vérifiez ensuite l’état et la disponibilité :

dockup status production/api --json
dockup uptime production/api --hours 24 --json

La supervision s’exécute chaque minute et inclut le temps de réponse p95. Un déploiement de configuration réussi doit tout de même faire l’objet d’une surveillance afin de détecter les régressions à l’exécution.

Pour la création d’un service et sa configuration initiale, suivez du repository Git à la production.

Valider la configuration sans la divulguer

Les applications doivent signaler clairement l’absence d’une clé requise, mais les diagnostics ne doivent pas afficher sa valeur. Un contrôle au démarrage peut renvoyer une liste telle que missing: ["DATABASE_URL"] ou invalid format: ["PUBLIC_URL"], puis se terminer avec un code différent de zéro.

Pour une valeur facultative, définissez la valeur de repli dans le code et documentez si cette valeur est sûre en production. Les valeurs par défaut silencieuses de développement — hôtes de bases de données locaux, modes de debug, CORS permissif ou identifiants de test — ne doivent pas être activées simplement parce qu’une clé de production est absente.

Cette validation rend les variables d’environnement et les secrets observables sans transformer les logs en inventaire d’identifiants.

Gérer délibérément plusieurs services et les identifiants partagés

Copier un même secret dans plusieurs services crée une dépendance lors de la rotation. Préférez des identifiants propres à chaque service lorsque le système externe le permet. Un token compromis d’un worker ne doit pas donner les mêmes accès que celui de l’API publique.

Lorsqu’une valeur partagée est inévitable, tenez à jour une liste de responsables et de consommateurs. Faites tourner tous les consommateurs pendant une fenêtre coordonnée et vérifiez les nouvelles connexions après chaque redéploiement. Ne demandez pas à un agent de « trouver tous les services qui utilisent probablement cette clé » en vous fondant sur la similarité des noms ; utilisez un inventaire explicite et des éléments d’audit.

Le réseau privé peut réduire l’exposition du trafic de base de données, mais il ne rend pas les identifiants inutiles. Les noms d’hôtes internes contrôlent le chemin ; l’authentification contrôle qui peut utiliser la base de données.

Commencer par un déploiement vérifiable

Classez chaque clé avant de la définir, vérifiez que les lectures de secrets sont masquées et incluez le redéploiement requis dans la même modification examinée.

Commencez gratuitement sur app.dockup.ai. Le forfait Free coûte 0 $ par mois, inclut un crédit initial de 10 $ et prend en charge un workspace, trois bases de données et trois déploiements.

FAQ

Dockup renvoie-t-il les valeurs secrètes stockées ?

Non. Les valeurs secrètes sont masquées dans les sorties de lecture. Les clés et les marqueurs de secret restent visibles afin que les opérateurs puissent vérifier que la configuration requise existe.

Pourquoi dois-je redéployer après avoir modifié une variable d’environnement ?

Le processus en cours d’exécution a reçu son environnement au démarrage. Un nouveau déploiement crée un nouveau container avec les valeurs mises à jour et le vérifie via le health gate.

Puis-je placer des secrets dans dockup.yaml ?

Non. Utilisez dockup.yaml pour la configuration standard vérifiable et les commandes d’environnement de secrets ou l’injection de secrets CI pour les identifiants.

Comment importer plusieurs variables d’environnement ?

Utilisez dockup env import avec un fichier de type .env et la cible exacte du service. Utilisez l’option import --secret uniquement si toutes les valeurs importées sont des secrets.

Que dois-je faire si un secret est exposé dans un log ?

Révoquez-le ou faites-le tourner immédiatement, mettez à jour le secret Dockup, redéployez, examinez les journaux d’accès et corrigez le processus à l’origine de la divulgation.