Définissez qui peut utiliser les secrets de déploiement, préparez leur rotation et vérifiez les accès du pipeline avant un changement de prestataire.
Le déploiement fonctionne, mais personne ne sait à quel compte appartient la clé utilisée. Quand son propriétaire quitte le projet, l’équipe hésite entre conserver un accès mal connu et interrompre les livraisons. Un inventaire des secrets permet de préparer ce changement sans attendre une panne.
Le point de départ est le parcours de déploiement : récupération du code, construction, publication puis installation. À chaque étape, identifiez le système contacté et l’autorisation demandée. Certaines étapes n’ont besoin d’aucun secret. D’autres peuvent utiliser une identité temporaire fournie par la plateforme.
Faire l’inventaire sans recopier les valeurs
Créez une fiche par accès utilisé. Elle contient le nom du secret dans le gestionnaire, son propriétaire, l’environnement concerné et la procédure de remplacement. La valeur reste dans l’outil prévu pour la stocker. Une feuille partagée sert au suivi des responsabilités, pas à distribuer des identifiants.
Pour chaque ligne, demandez au développeur de retrouver l’étape qui consomme cet accès. Un secret dont personne ne connaît l’usage doit être examiné avant sa suppression. Recherchez notamment les traitements occasionnels : publication d’une version, restauration ou tâche de maintenance.
| Information | Question à résoudre |
|---|---|
| Compte ou identité | Qui possède cet accès côté fournisseur ? |
| Ressource autorisée | Sur quel service peut-il agir ? |
| Environnement | Production, préproduction ou développement ? |
| Consommateur | Quel travail automatisé en a besoin ? |
| Remplacement | Qui peut créer puis révoquer une valeur ? |
Consignez aussi les accès utilisés manuellement pendant une intervention. Si le déploiement normal est automatisé mais que la reprise dépend d’un ancien compte personnel, votre inventaire reste incomplet.
Limiter la distribution au travail concerné
GitHub Actions distingue les secrets de dépôt, d’environnement et d’organisation. Le périmètre choisi détermine comment les workflows peuvent les recevoir. La documentation précise également des restrictions pour les événements issus de forks et les workflows réutilisables ; vérifiez ces règles avant de contourner une absence de secret dans un test.
Dans votre pipeline, faites apparaître le moment où un accès de production devient nécessaire. Les vérifications du code et les tests qui n’en ont pas besoin doivent rester exécutables sans cet accès. Pour une publication, préférez une autorisation sur le registre concerné à un compte permettant d’administrer toute l’organisation.
Examinez les personnes capables de modifier la définition du workflow. Elles peuvent changer ce que fait le programme auquel un secret est remis. La revue du fichier de pipeline mérite donc une attention particulière, y compris lorsque la modification paraît limitée à un outil de test.
Étudier les identités temporaires disponibles
Avec un fournisseur compatible, OpenID Connect dans GitHub Actions permet à un workflow d’obtenir une autorisation cloud sans conserver une clé d’accès de longue durée dans GitHub. Le fournisseur vérifie l’identité présentée et applique la relation de confiance configurée.
La revue doit porter sur cette relation : quel dépôt, quelle branche ou quel environnement peut demander quel rôle ? Recopier une configuration d’exemple sans adapter ces conditions peut donner accès à un périmètre plus large que prévu. Faites valider un scénario autorisé et un scénario qui doit être refusé.
Prévoyez cette évolution service par service. Certains outils externes peuvent encore demander une clé durable. Notez leur mode de renouvellement et leur propriétaire, sans présenter OIDC comme une solution applicable à tous les accès du pipeline.
Préparer une rotation qui peut être vérifiée
Prenons un registre d’images fictif. Avant de remplacer sa clé, listez les pipelines qui publient et ceux qui téléchargent. Vous pouvez découvrir qu’un accès unique sert à plusieurs applications. Décidez si le remplacement doit conserver cette organisation ou séparer les droits.
La procédure dépend ensuite du fournisseur. S’il permet plusieurs clés actives, préparez la nouvelle valeur, modifiez les consommateurs puis vérifiez leur fonctionnement avant de révoquer l’ancienne. S’il n’accepte qu’une clé, organisez la fenêtre de changement et le traitement des exécutions en cours.
Gardez une preuve du test : identité utilisée, pipeline exécuté et résultat attendu. Confirmez enfin que l’ancien accès est révoqué. Le simple succès d’un déploiement ne prouve pas que tous les consommateurs ont abandonné la valeur précédente.
En cas de fuite avérée, la priorité et le calendrier changent : suivez la procédure d’incident et révoquez l’accès compromis selon son risque. La méthode de rotation planifiée ne doit pas retarder cette décision.
Contrôler les sorties du pipeline
Relisez les journaux d’un déploiement représentatif avec des données de test. Recherchez les sorties de configuration complètes, les fichiers joints et les commandes de diagnostic trop bavardes. Vérifiez également ce qui est conservé dans les artefacts accessibles aux autres collaborateurs.
Le masquage automatique constitue une aide, mais votre pipeline doit éviter d’imprimer les secrets. GitHub recommande notamment d’éviter leur passage sur la ligne de commande lorsque d’autres mécanismes conviennent. Notre guide de journalisation applicative propose la même discipline pour les événements produits par l’application.
Lors d’une reprise de maintenance, faites démontrer un déploiement et une rotation avec les comptes de l’organisation. Ajoutez les résultats au dossier de transfert, puis retirez les accès du prestataire sortant selon la liste des consommateurs vérifiée.