Confiez à un identifiant de déploiement une seule tâche étroite

Séparez l'automatisation et l'administration personnelle

Un pipeline d'API de reporting doit sélectionner un artefact approuvé et invoquer une action de version contrôlée. Cela ne nécessite pas automatiquement de créer des utilisateurs, modifier la facturation ou lire tous les secrets de l'application. Commencez par un inventaire des permissions et un environnement de test protégé ; gardez les identifiants hors des documents, dépôts et journaux d'exemple.

L'accès humain à la récupération doit rester séparé afin que la révocation d'un identifiant de déploiement ne supprime pas le seul chemin d'investigation. Identifiez un mainteneur autorisé et une vérification d'hôte indépendante. Une seconde clé non restreinte est un autre identifiant, pas un rôle plus étroit.

Décrivez précisément l'opération autorisée

Validez les entrées de l'action de version. Une commande restreinte qui concatène du texte arbitraire dans un shell privilégié permet encore un travail non intentionnel. Examinez ensemble le comportement du wrapper, les chemins accessibles en écriture et la confiance des artefacts. Des privilèges sudo étendus ou l'accès au socket Docker peuvent défaire la frontière prévue.

Traitez les modifications de flux de travail comme un accès aux identifiants

Quelqu'un capable de modifier des étapes de flux de travail de confiance peut utiliser ou exposer ses identifiants. Examinez les permissions du dépôt, les environnements de déploiement protégés et les événements qui exécutent des tâches privilégiées. Gardez les identifiants de production à l'écart du code de demande de tirage non fiable. Accordez à un jeton de flux de travail uniquement les permissions dont sa tâche a besoin.

GitHub recommande l'épinglage par SHA de commit complet pour une sélection d'action immuable. Examinez l'action sélectionnée et les mises à jour ultérieures ; une balise de version peut se déplacer. Évitez d'insérer directement des données d'événement non fiables dans du code shell en ligne. Le masquage des valeurs de secret connues n'est pas une garantie contre la divulgation via des transformations, journaux ou artefacts.

Référence technique : Utilisation sécurisée de GitHub Actions.

Utilisez une durée de vie courte lorsque la destination le permet

OpenID Connect peut permettre à une destination prise en charge d'échanger l'identité de flux de travail contre un identifiant de courte durée. Configurez des vérifications de confiance pour le dépôt, la branche ou l'environnement et l'audience prévus. Ce n'est ni un remplacement universel de SSH ni une fonctionnalité fournie par le frontend actuel PrivacyNodes.

Si votre déploiement utilise SSH, examinez les options de clé autorisée du paquet installé. Une commande forcée seule n'interdit pas le transfert ; les restrictions doivent couvrir les chemins d'accès prévus et toujours invoquer une opération de version sûre. Testez dans un environnement séparé. Préservez l'administration et l'accès de récupération fonctionnels lors du changement d'authentification, et vérifiez une nouvelle connexion indépendante avant de supprimer l'ancienne méthode.

Référence technique : OpenID Connect de GitHub Actions · format OpenSSH authorized_keys.

Testez les tâches autorisées et interdites

Vérifiez que l'identité peut sélectionner l'artefact prévu, invoquer la version et obtenir un résultat utile. Testez ensuite ses limites : les secrets d'une autre application, les modifications de fichiers non liées et l'administration arbitraire doivent être indisponibles. Incluez les chemins d'artefact et les arguments que le wrapper doit rejeter.

Enregistrez l'identité, la portée, l'expiration le cas échéant, le mainteneur approbateur et l'emplacement des preuves d'audit. Conservez des références de stockage plutôt que des valeurs d'identifiants. Si un test ne fonctionne qu'après avoir accordé une large administration, révisez la tâche de version au lieu d'en faire silencieusement le rôle permanent.

Répétez la révocation et une version de pipeline cassé

Préparez un remplacement avec la portée révisée, vérifiez un déploiement de test, basculez le pipeline et révoquez l'ancienne identité. Confirmez que l'identifiant remplacé échoue et qu'aucun doublon ne subsiste dans un autre flux de travail. L'ajout d'une nouvelle clé seule ne supprime pas l'accès précédent.

Documentez comment un mainteneur autorisé arrête le déploiement et récupère lorsque la CI est indisponible. Liez cette procédure à l' fiche de version et inventaire de récupération. Un identifiant étroit limite l'autorité prévue ; il ne rend pas un artefact malveillant inoffensif.