Avec les protections d’exécution des flux de travail, vous pouvez définir une liste d’autorisation qui contrôle qui peut déclencher les GitHub Actions flux de travail et quels événements sont autorisés à les déclencher. Pour plus d’informations, consultez À propos des stratégies Actions.
Remarque
GitHub a ajouté une stratégie par défaut qui bloquera l’événement pull_request_target dans les référentiels publics. Cette stratégie sera appliquée le 2 novembre 2026. Consultez « Utilisation sécurisée de pull_request_target ».
Préparation à l’ajout de protections
Comme les ensembles de règles, les protections d’exécution des flux de travail se superposent aux autres protections dans le même référentiel, la même organisation ou la même entreprise.
Au lieu de créer une stratégie volumineuse par compte, nous vous recommandons de créer plusieurs stratégies clairement définies et des protections de couche entre les niveaux de compte. Les propriétaires d’entreprise peuvent créer des protections au niveau de l’entreprise pour des stratégies larges et non négociées. Les propriétaires de l’organisation et les administrateurs de référentiels peuvent ensuite ajouter à ces restrictions.
Pour chaque stratégie que vous définissez, pensez à :
-
Quelles organisations ou référentiels votre protection ciblera. Par exemple, les dépôts open source peuvent nécessiter des restrictions plus strictes quant aux personnes autorisées à déclencher des flux de travail. Vous pouvez cibler des référentiels en fonction de facteurs tels que la visibilité, l’état du déploiement ou la propriété personnalisée.
- L’état du déploiement provient de l’linked artifacts pageorganisation. S’il s’agit d’un facteur important, vérifiez que vous chargez des enregistrements de déploiement lorsqu’un artefact est déployé. Consultez « À propos des artefacts liés ».
- Pour créer et affecter des propriétés personnalisées, consultez Gestion des propriétés personnalisées pour les référentiels de votre organisation.
-
Quels flux de travail seront protégés. Par exemple, les flux de travail qui déploient du code de production peuvent nécessiter un certain niveau de protection, mais les automatisations moins sensibles peuvent ne pas avoir besoin du même niveau de protection. Vous pouvez étendre les stratégies à des chemins de flux de travail spécifiques ou à des flux de travail requis.
-
Qui doit être en mesure d’exécuter ces flux de travail dans les référentiels que vous ciblez. Il peut s’agir d’utilisateurs disposant d’un certain rôle, de comptes de bot sélectionnés ou d’une équipe spécifique. Envisagez de regrouper ces utilisateurs dans une organisation ou une équipe d’entreprise afin qu’ils puissent être facilement contactés et référencés sur plusieurs ensembles de règles. Consultez Créer une équipe d’organisation ou Création d’équipes d’entreprise.
Création d’une stratégie d’exécution de flux de travail
Tout d’abord, créez une stratégie Actions pour le niveau de compte auquel vous travaillez.
Dans un référentiel ou une organisation :
- Cliquez sur l’onglet Paramètres.
- Dans la barre latérale gauche, sous Actions, cliquez sur Stratégies.
Dans une entreprise :
- Cliquez sur l’onglet Stratégies .
- Dans la barre latérale gauche, cliquez sur Actions, puis Stratégies.
Conseil
Pour gérer les stratégies par programmation, consultez Points de terminaison d’API REST pour les stratégies de GitHub Actions.
Configuration de la stratégie
Ensuite, créez une stratégie.
- Choisissez un nom pour la stratégie.
- Choisissez un état d’application. Si vous sélectionnez Évaluer (GitHub Enterprise Cloud uniquement), vous serez en mesure de surveiller quand les utilisateurs atteignent la restriction dans les insights de stratégie.
- Ciblez vos flux de travail, organisations ou référentiels souhaités.
- Configurez les protections d’exécution de flux de travail suivantes.
Restreindre les acteurs
Par défaut, chaque utilisateur disposant d’un accès en écriture à un référentiel peut déclencher des flux de travail. Les règles d’acteur vous permettent de séparer les personnes qui contribuent au code des personnes qui exécutent votre ci, afin de pouvoir accorder un accès en écriture contributeur sans leur accorder la possibilité d’exécuter des flux de travail.
Seuls les acteurs autorisés pourront exécuter les flux de travail spécifiés dans le référentiel ciblé. Si vous limitez également les événements, ces utilisateurs peuvent uniquement déclencher des flux de travail avec les événements autorisés. Les acteurs non autorisés ne pourront pas exécuter les flux de travail spécifiés du tout.
GitHub fonctionnalités sont exemptées de ces restrictions pour les processus intégrés sur lesquels elles s’exécutent GitHub Actions. Toutefois, si vous avez créé des flux de travail qui doivent être exécutés par l’identité associée à une GitHub fonctionnalité, par dependabot[bot]exemple, cette identité doit être ajoutée en tant qu’acteur autorisé.
Restreindre les événements
Les règles d’événement contrôlent les événements autorisés, tels que push, , pull_request``pull_request_target, et workflow_dispatch.
Évaluation des stratégies
Vous pouvez afficher les analyses de stratégie pour voir les exécutions du workflow qui ont été bloquées (pour les stratégies actives) ou qui auraient été bloquées (pour les stratégies définies sur « Évaluer »). Il s’agit d’un bon moyen de vérifier que les stratégies fonctionnent comme prévu et ne provoquent pas de frictions inutiles.
Pour afficher les insights, cliquez sur la page Insights de stratégie . Vous trouverez cela directement sous la page des GitHub Actions règles dans la barre latérale de votre dépôt, organisation ou entreprise.