Sécurité
Comment garder les secrets hors du code source
Les noms de variables d’environnement peuvent figurer dans un manifeste. Les identifiants d’accès, non. Les références aux secrets préservent cette limite du travail local jusqu’à la production.
Un secret placé une fois dans le dépôt peut persister dans les clones, caches, journaux et anciens commits longtemps après la suppression de la ligne visible.
Versionner la référence, pas la valeur
Le code applicatif a besoin de noms de variables d’environnement stables, pas des identifiants de production qu’ils représentent. Dans un manifeste Adios, une référence à un secret déclare la dépendance sans placer sa valeur dans le dépôt.
Le contrat de déploiement reste ainsi vérifiable. Un collègue peut voir que l’application attend DATABASE_URL ou STRIPE_SECRET_KEY, tandis que l’accès à la valeur sous-jacente est contrôlé séparément.
env:
DATABASE_URL: secret://DATABASE_URL
API_SIGNING_KEY: secret://API_SIGNING_KEYDistinguer les besoins de la compilation et de l’exécution
Certains identifiants ne sont requis que lors de l’installation des dépendances ou de la récupération du code privé. D’autres sont nécessaires au processus en cours d’exécution. Donner chaque secret aux deux phases augmente inutilement la surface d’exposition.
Limitez chaque valeur au chemin qui l’utilise et n’affichez pas les secrets résolus dans les résultats de compilation, les journaux d’exécution ou les messages d’erreur. Un gestionnaire de secrets ne peut pas protéger un identifiant que l’application réécrit dans un journal public.
- —Compilation uniquement : jetons de paquets privés et clés de déploiement Git.
- —Exécution uniquement : mots de passe de base de données, clés de signature et identifiants d’API des prestataires.
- —Les deux phases seulement lorsque la même valeur est réellement requise par les deux.
Faire de la rotation une opération courante
Un identifiant d’accès devra un jour être renouvelé. Choisissez des noms et un comportement applicatif qui permettent de remplacer sa valeur sans modifier le code source. Pour les accès sensibles, prévoyez un chevauchement durant lequel les anciennes et nouvelles valeurs sont acceptées pendant le redémarrage des workloads.
Si un secret arrive dans Git, renouvelez-le d’abord, puis nettoyez le dépôt. Supprimer la ligne est utile, mais ne rend pas à nouveau sûre la valeur exposée.
- —Créez le nouvel identifiant d’accès sans désactiver l’ancien.
- —Mettez à jour la valeur stockée et redéployez les workloads avec le nouvel identifiant.
- —Vérifiez dans les journaux et l’activité du prestataire que le nouvel identifiant est utilisé.
- —Révoquez l’ancien identifiant et enregistrez l’heure de rotation.
Réagir à un identifiant placé dans le dépôt
Supposons qu’un développeur versionne une URL de base de données, la supprime au commit suivant, puis force l’envoi de la branche. Considérez malgré tout le mot de passe comme exposé : un clone, une récupération CI, un index d’éditeur ou un cache de pull request peut déjà le contenir.
Désactivez ou renouvelez l’identifiant, examinez les traces d’audit du prestataire, cherchez dans les journaux les affichages accidentels, puis seulement nettoyez l’historique du dépôt. Réécrire l’historique limite les découvertes futures ; renouveler l’identifiant supprime l’accès actuel.