Gestion des clés OpenShip : plateforme ou serveur ?

Symptôme : la clé n’est pas écrite dans le code, mais elle apparaît dans une couche d’image, un journal de compilation ou un paquet frontend.

Solution la plus rapide : placez les clés applicatives dans les secrets OpenShip séparés par environnement, gardez sur le serveur uniquement les identifiants indispensables à l’infrastructure et validez une rotation complète avant la mise en production.

Cette règle convient aux équipes qui déploient un SaaS, un agent ou une API avec OpenShip. Un fichier .env hors dépôt peut rester acceptable pour un prototype local très limité ; dès qu’une prévisualisation, une équipe ou une base de production entre en jeu, la gestion des clés OpenShip doit devenir un processus contrôlé.

Cette page s’adresse au développeur qui configure sa première clé de modèle, à l’équipe qui sépare les environnements de prévisualisation, de test et de production, ainsi qu’au responsable de publication chargé des permissions, de l’audit et de la reprise après incident.

Le point de rupture : une clé absente du code peut finir dans l’image

Prenons un cas fréquent. Vous ajoutez une clé d’API dans un fichier local, vous l’excluez de Git, puis vous utilisez une instruction ARG, une variable ENV ou une copie temporaire pendant la construction Docker. Le fichier source reste propre, mais la valeur peut persister dans une couche de l’image ou apparaître dans la sortie d’une commande de compilation.

Une image de conteneur est composée de couches de modifications. Supprimer une valeur dans une couche ultérieure ne suffit donc pas à effacer son apparition précédente. La documentation Docker sur les couches d’image explique ce fonctionnement et le risque associé aux fichiers copiés puis supprimés pendant la construction.

Vous devez contrôler l’ensemble de la chaîne, et pas seulement le fichier actuellement ouvert :

• l’historique Git, y compris les branches et les anciennes versions supprimées ;
• le Dockerfile, les arguments de construction et les scripts de déploiement ;
• les journaux de compilation, de test et de publication ;
• les artefacts produits par le build ;
• le paquet client livré au navigateur ou à une application mobile.

Les clés destinées exclusivement au serveur ne doivent jamais être injectées dans une variable exposée au frontend. Une variable prévue pour être intégrée au bundle client n’est pas un secret, même si son nom contient API_KEY. Le navigateur, les outils de développement et les requêtes réseau peuvent rendre sa valeur visible.

Pour une clé nécessaire pendant la construction, utilisez un mécanisme de montage temporaire plutôt qu’un argument persistant. La documentation Docker sur les secrets de build distingue précisément les valeurs transmises comme arguments ou variables d’environnement des secrets montés temporairement pendant le processus de construction.

Les variables d’environnement OpenShip peuvent-elles finir dans l’image ?

Une variable configurée pour l’exécution de l’application ne doit pas être considérée automatiquement comme une variable de construction. Vous devez vérifier à quel moment OpenShip l’injecte : pendant le build, au démarrage du conteneur, ou dans les deux phases.

Si l’application a besoin d’une clé uniquement lorsqu’elle traite une requête, cette clé doit être fournie au moment de l’exécution. Elle ne doit pas être copiée dans l’artefact. Contrôlez également les scripts qui affichent la configuration, les commandes de diagnostic et les outils qui produisent un rapport de build. Une clé masquée dans l’interface peut tout de même apparaître en clair dans une sortie de commande.

Avant de publier, recherchez les noms de variables sensibles dans les fichiers générés, inspectez les métadonnées de l’image et examinez les logs de construction. Si une clé a déjà été exposée, ne vous contentez pas de supprimer le fichier : révoquez-la, créez une nouvelle valeur et recherchez toutes les copies historiques.

L’isolement des environnements

Le deuxième risque n’est pas toujours une fuite externe. Il s’agit souvent d’une erreur interne : une prévisualisation utilise la base de données de production, un test consomme le compte de modèle officiel ou une branche temporaire envoie de vrais courriels à des utilisateurs.

OpenShip présente une séparation des secrets par environnement dans son flux de déploiement. Cette capacité doit toutefois être vérifiée dans votre installation et dans votre mode de déploiement. Une fonctionnalité décrite par la documentation ne constitue pas, à elle seule, une preuve que vos projets sont correctement isolés.

Pour chaque environnement, utilisez des valeurs distinctes :

• prévisualisation : clé limitée, compte de démonstration et données non sensibles ;
• test : compte réservé aux tests automatisés ou service simulé ;
• production : clé avec les droits strictement nécessaires, accessible aux publications approuvées.

Évitez de copier les variables de production vers une prévisualisation pour gagner du temps. Le risque n’est pas seulement qu’une personne lise la clé. Un script exécuté dans cette prévisualisation pourrait appeler une API coûteuse, modifier des données ou déclencher une tâche irréversible.

Comment utiliser des clés différentes entre la prévisualisation et la production ?

Commencez par créer deux entrées portant le même nom logique, mais appartenant à deux environnements distincts. Déployez ensuite une version qui expose uniquement un indicateur non sensible, comme le nom de l’environnement, afin de confirmer que la résolution est correcte.

Utilisez une clé de test volontairement limitée et vérifiez dans les journaux du fournisseur de modèle que la prévisualisation n’emploie pas le compte de production. Répétez ce contrôle avec la base de données, le système d’envoi de courriels, le stockage de fichiers et les services de paiement.

Le point important est la responsabilité de configuration. Avec un fichier .env, vous devez gérer vous-même la copie vers le bon serveur, les permissions du fichier, la sauvegarde, la rotation et la traçabilité. Avec les secrets de plateforme, OpenShip peut centraliser l’association entre projet et environnement, mais vous devez confirmer les droits réels et le comportement de votre déploiement.

La documentation de démarrage d’OpenShip décrit la configuration des variables d’environnement dans le flux de publication. Elle ne suffit pas nécessairement à démontrer qu’une modification est propagée instantanément à tous les processus déjà actifs. Cette vérification doit être réalisée sur votre application.

La rotation sans interruption

Une rotation réussie ne se résume pas à voir une confirmation d’enregistrement dans une console. Vous devez démontrer que la nouvelle clé est utilisée, que l’ancienne peut être révoquée et qu’un échec permet de revenir à une situation contrôlée.

Le remplacement direct est la méthode la plus rapide, mais aussi la plus risquée. Si l’application conserve l’ancienne valeur en mémoire ou si certains travailleurs ne redémarrent pas, une partie des requêtes peut échouer tandis qu’une autre continue de fonctionner.

Une procédure plus sûre consiste à organiser une courte coexistence entre l’ancienne et la nouvelle valeur :

• créer une nouvelle clé avec le même périmètre minimal ;
• l’ajouter à l’environnement concerné sous une référence temporaire ;
• publier une version capable d’utiliser cette référence ;
• envoyer une requête de contrôle ;
• observer les erreurs et la consommation ;
• révoquer l’ancienne clé ;
• supprimer la référence temporaire après validation.

Le changement d’une clé API nécessite-t-il un nouveau déploiement ?

Cela dépend du moment où OpenShip injecte la valeur et de la manière dont votre processus relance les conteneurs. Une modification peut être disponible au prochain démarrage sans nécessiter une nouvelle construction d’image, mais un processus déjà actif peut conserver l’ancienne valeur en mémoire.

Testez séparément les comportements suivants :

• modification de la valeur puis nouvelle requête sur une instance existante ;
• modification suivie d’un redémarrage applicatif ;
• modification suivie d’un nouveau déploiement.

Ne déduisez pas le résultat à partir du seul bouton de sauvegarde. Le test utile consiste à provoquer une requête réelle, à identifier la clé utilisée sans révéler sa valeur, puis à révoquer l’ancienne et à confirmer que les appels attendus continuent de fonctionner.

Pour un service critique, consignez l’environnement, le propriétaire du changement, le résultat du test et l’heure de révocation. Ne copiez jamais la clé dans ce compte rendu ; utilisez son identifiant, son fournisseur et, si nécessaire, une empreinte partielle.

Expérience d’exploitation : une valeur affichée comme masquée dans le tableau de bord peut tout de même apparaître dans un journal, un shell de débogage ou le cache d’un outil de publication. La preuve utile est le test de rotation, pas l’apparence de l’interface.

Les permissions et la traçabilité

Une équipe n’a pas besoin de donner le même accès à toutes les personnes qui contribuent au projet. Séparez au minimum les responsabilités de développement, de publication, d’administration et d’audit.

Le rôle de développement doit permettre de modifier le code et de publier une prévisualisation, sans donner automatiquement accès à la valeur brute des secrets de production. Le rôle de publication doit pouvoir promouvoir une version approuvée, mais ne devrait pas nécessairement pouvoir lire ou exporter les clés. Le rôle d’administration doit gérer les valeurs, les membres et les révocations. Le rôle d’audit doit consulter les événements sans modifier la configuration.

OpenShip décrit des rôles, des permissions et des capacités d’audit dans sa documentation. Ces informations doivent être considérées comme des fonctionnalités à vérifier, particulièrement lorsque vous utilisez une installation auto-hébergée, une offre cloud ou une architecture hybride. Les droits réellement disponibles peuvent dépendre du mode d’exécution et de la version installée.

Votre test doit répondre à des questions concrètes :

• un développeur peut-il lire la valeur brute ou seulement modifier une référence ?
• un membre autorisé à publier peut-il cibler la production depuis une branche de prévisualisation ?
• un administrateur peut-il révoquer une clé sans validation secondaire ?
• chaque modification indique-t-elle l’identité, l’heure, l’environnement et la ressource concernée ?
• les jetons d’automatisation possèdent-ils un périmètre inférieur à celui de leur créateur ?

La même logique s’applique aux agents qui utilisent une API ou un outil d’automatisation. Ne fournissez pas à un agent un jeton personnel disposant de droits d’administration si sa tâche consiste uniquement à lire l’état d’un déploiement ou à déclencher une publication limitée.

Pour réduire le risque de dépôt accidentel, activez une protection contre les secrets dans votre forge. La protection contre l’envoi de secrets proposée par GitHub peut bloquer certains identifiants avant leur arrivée dans l’historique, mais elle ne remplace ni la rotation ni la vérification des images et des journaux.

Quels droits donner aux membres de l’équipe ?

Donnez d’abord le droit nécessaire à la tâche, puis vérifiez si la personne peut lire, modifier, publier ou révoquer une valeur. Ces actions ne doivent pas être regroupées par défaut.

Un développeur qui travaille sur une interface audio ou vidéo peut avoir besoin de publier une prévisualisation afin de tester un traitement distant, sans pouvoir toucher au compte de modèle de production. Un responsable du design peut vérifier une intégration visuelle sans recevoir la clé d’un service de paiement. Un opérateur de publication peut relancer un déploiement sans obtenir la possibilité d’exporter les secrets.

La reprise après panne

Une sauvegarde de base de données ne garantit pas que l’application redémarrera. Après la restauration d’un serveur, il peut manquer les variables de production, la clé de chiffrement de l’application, les identifiants de registre, les certificats, les clés SSH ou les autorisations nécessaires pour recréer les secrets.

Distinguez trois catégories de sauvegarde :

• les données applicatives : base de données, fichiers utilisateurs et objets stockés ;
• la configuration de déploiement : noms d’environnements, références de secrets, règles de publication et paramètres réseau ;
• les valeurs secrètes : conservées dans une fonction de secrets contrôlée ou dans un coffre externe, avec une procédure de récupération séparée.

Ne sauvegardez pas un fichier contenant toutes les clés de production en clair dans le même emplacement que les sauvegardes applicatives. Si vous utilisez un Secrets Vault externe, réservez-le aux valeurs qui justifient ce niveau de contrôle : identifiants d’infrastructure, clés longue durée, certificats ou accès soumis à une validation renforcée.

Les recommandations de l’OWASP sur la gestion des secrets insistent sur le stockage, la distribution, l’audit, la rotation et la limitation des autorisations. Dans un exercice de reprise, vérifiez également qui peut réautoriser l’accès. Si cette personne est absente et qu’aucun mécanisme de secours n’existe, la sauvegarde est inutilisable au moment critique.

Vous devez pouvoir reconstruire l’application sans rechercher une clé dans les messages privés d’un ancien membre de l’équipe. Documentez le chemin de récupération, les personnes autorisées, les validations nécessaires et la méthode de révocation après restauration. Pour clarifier les responsabilités liées aux données, aux accès et aux services distants, vous pouvez aussi consulter le centre juridique de Macstripe avant de formaliser votre procédure interne.

Le stockage adapté à chaque type de secret

Utilisez une séparation par catégorie plutôt qu’une opposition générale entre plateforme et serveur.

Les clés applicatives

Pour les clés de modèles, d’email, de paiement ou de services consommés par l’application, choisissez en priorité les secrets OpenShip isolés par environnement, à condition d’avoir vérifié les droits, les journaux et le comportement de rotation.

Points favorables :

• séparation plus claire entre prévisualisation, test et production ;
• modification sans changement du code source ;
• responsabilité centralisée lors des publications ;
• association plus lisible entre projet, environnement et valeur.

Limites :

• les capacités peuvent varier entre cloud, auto-hébergement et déploiement hybride ;
• une mauvaise permission de projet peut exposer trop de secrets ;
• la récupération dépend de la sauvegarde de la plateforme et des comptes administrateurs.

Les identifiants d’infrastructure

Les clés SSH, les accès à un registre privé ou les certificats nécessaires au serveur peuvent rester dans le système cible ou dans un coffre externe intégré au processus de déploiement. Ils ne doivent pas être placés dans le .env de l’application si un composant applicatif peut les lire.

Les jetons temporaires

Pour une construction, une migration ou une opération ponctuelle, préférez un jeton à durée courte et à portée limitée. Supprimez-le après l’opération, même si le déploiement semble réussi.

Les secrets de production très sensibles

Pour un projet qui traite des paiements, des données privées ou plusieurs comptes fournisseurs, adoptez une stratégie en couches :

• OpenShip pour les variables applicatives liées à l’environnement ;
• le système d’exécution pour les identifiants strictement nécessaires à l’infrastructure ;
• un Secrets Vault pour les valeurs à forte sensibilité, les clés longue durée et les accès soumis à une validation renforcée.

Le serveur .env reste acceptable pour un prototype contrôlé ou une installation personnelle, à condition qu’il soit hors dépôt, protégé par les permissions du système et couvert par une procédure de restauration. Il devient un mauvais choix lorsque plusieurs personnes doivent le modifier, lorsque plusieurs serveurs doivent rester synchronisés ou lorsque l’équipe ne peut pas reconstituer l’historique des changements.

La checklist avant la production

• [ ] Rechercher les anciennes clés dans l’historique Git, les branches et les fichiers supprimés.
• [ ] Inspecter le Dockerfile, les arguments de build, les journaux et les artefacts produits.
• [ ] Vérifier que les variables serveur ne sont pas intégrées dans le bundle frontend.
• [ ] Créer des valeurs distinctes pour la prévisualisation, le test et la production.
• [ ] Confirmer qu’une prévisualisation ne peut pas joindre la base ni le compte de modèle de production.
• [ ] Tester la modification d’une clé sans supposer qu’un redéploiement est inutile.
• [ ] Vérifier qu’une nouvelle requête utilise effectivement la nouvelle valeur.
• [ ] Révoquer l’ancienne clé et observer les erreurs attendues.
• [ ] Tester séparément les comptes de développement, de publication, d’administration et d’audit.
• [ ] Vérifier les événements dans les journaux sans enregistrer la valeur brute.
• [ ] Documenter la restauration des références, des autorisations et des secrets.
• [ ] Réaliser un exercice de reprise avec une personne différente de celle qui a conçu le déploiement.

La documentation d’aide en français de Macstripe peut compléter cette préparation si votre chaîne de publication dépend d’un environnement distant ou d’un poste de construction partagé. Si votre équipe utilise également une machine distante pour compiler, vérifiez que les identifiants personnels ne sont pas copiés dans les scripts communs et que l’accès peut être révoqué sans interrompre les autres projets.

Le choix recommandé

Pour une application OpenShip classique, placez les clés de modèle et les autres secrets applicatifs dans la fonction de secrets de la plateforme, séparée par environnement et contrôlée par des rôles testés. Gardez dans le serveur uniquement ce qui est indispensable au fonctionnement de l’infrastructure. Ajoutez un Secrets Vault lorsque la criticité, la durée de vie ou les exigences d’audit dépassent ce que votre instance OpenShip peut démontrer.

Le fichier .env sur serveur n’est donc pas interdit ; il est simplement rarement adapté comme source principale pour une équipe qui publie régulièrement. Il augmente les risques de dérive entre machines, de sauvegarde incomplète, de modification non tracée et de restauration impossible. La plateforme, elle, ne devient pas automatiquement sûre parce qu’elle affiche une interface de secrets : vous devez confirmer l’isolement, les permissions et la rotation sur votre propre mode de déploiement.

Si votre chaîne actuelle repose sur un poste local partagé, une machine de construction toujours connectée ou des identifiants personnels transmis entre développeurs, vous cumulez une dépendance à une personne, un accès difficile à révoquer et une absence de preuve fiable après incident. Louer un environnement Mac avec Macstripe peut alors offrir une séparation plus nette entre poste de développement, construction et livraison, notamment pour les projets audio, vidéo ou design qui nécessitent une chaîne Apple disponible à distance.

Avant de choisir cette option, vérifiez toutefois que votre équipe n’a pas besoin d’un contrôle physique permanent ou d’une charge lourde stable qui rendrait un achat direct plus rationnel. Pour un environnement temporaire, une validation de pipeline ou une construction distante, la séparation des accès et des identifiants est souvent le bénéfice le plus concret.