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.
Exiger un lockfile
La protection Require lockfile bloque les exécutions de flux de travail avec uses: des dépendances sur d’autres actions, sauf si les dépendances sont épinglées dans un fichier de verrou de dépendance. Cela garantit que les flux de travail ciblés exécutent un code prédictible et vérifié, plutôt que le contenu vers lequel une balise ou une branche pointe au moment de l’exécution. Consultez « Fichiers de verrouillage des dépendances du workflow ».
Générez et vérifiez les fichiers de verrou dans les référentiels que vous ciblez avant de définir cette protection sur Active. Sinon, vous bloquerez les exécutions de flux de travail dans les référentiels qui ne sont pas prêts. Pour un déploiement progressif, consultez Imposer l’utilisation de fichiers de verrouillage pour les dépendances d’action.
Vous pouvez conserver Exiger que les actions soient épinglées à un SHA de commit complet activé lors de l’adoption de fichiers de verrouillage. Pour les dépendances couvertes par un fichier de verrouillage, GitHub évalue cette exigence à l’aide du SHA du commit verrouillé. Le fait de laisser la stratégie activée lors d’un déploiement progressif conserve l’application de l’épinglage SHA pour les flux de travail qui n’ont pas encore adopté de fichiers de verrouillage.
É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.