Comment gérez-vous les secrets dans un pipeline de build et de déploiement ?

Gardez les identifiants à longue durée de vie complètement hors du pipeline. Utilisez la fédération d'identité de charge de travail pour que le job de CI échange un jeton OIDC de courte durée contre un rôle limité, et récupérez les secrets applicatifs à l'exécution depuis un gestionnaire de secrets plutôt que de les injecter au build. Limitez chaque secret à un environnement et un consommateur, faites la rotation automatiquement, auditez les accès, et masquez-les dans les logs. Ne cuisez jamais des secrets dans des images et ne les committez pas, même chiffrés, sans gestion de clés.

Ma position de départ, c'est que le pipeline ne doit détenir aucun identifiant cloud à longue durée de vie. Le fournisseur de CI émet un jeton d'identité signé pour le job, le cloud fait confiance à cet émetteur, et le job l'échange contre un rôle qui dure quelques minutes et se limite à un environnement. Ça supprime toute la catégorie de la clé statique qui a fuité et qui dort dans un réglage de dépôt depuis trois ans. Les secrets applicatifs sont un sujet distinct et leur place est à l'exécution, récupérés depuis un gestionnaire de secrets par la charge de travail avec sa propre identité, comme ça un mot de passe de base de données ne passe jamais par le build. Si je dois garder des secrets chiffrés dans git, par exemple dans un dépôt GitOps, ils sont chiffrés avec un service de gestion de clés, donc ce que je contrôle vraiment c'est le droit de déchiffrer, pas le fichier. Tout est cloisonné étroitement, tourné à intervalles réguliers, et les accès sont journalisés. Et je prévois les fuites : révoquer d'abord, faire la rotation, puis établir le rayon d'impact depuis la piste d'audit, parce qu'essayer de prouver que personne ne s'en est servi avant de révoquer, c'est l'ordre inverse.