Application de stratégies pour GitHub Actions dans votre entreprise

Quelles sont les stratégies pour GitHub Actions ?

Les stratégies d’entreprise contrôlent les options disponibles pour les membres d’entreprise lorsqu’elles utilisent GitHub Actions.

Si vous n’appliquez pas de stratégies d’entreprise, les propriétaires d’organisation s et les utilisateurs disposant de l’autorisation « Gérer les stratégies d’actions de l’organisation » ont un contrôle total sur GitHub Actions pour leurs organisations.

Application de politiques

1. Accédez à votre entreprise. Par exemple, depuis la page Entreprises sur GitHub.com.
2. En haut de la page, cliquez sur Stratégies.
3. Sous «  Politiques », cliquez Actions.
4. Après avoir configuré chaque stratégie, cliquez sur Enregistrer.

Pour plus d’informations sur chaque section de la page « Stratégies », poursuivez la lecture.

Stratégies

Dans la section « Stratégies », vous pouvez contrôler quelles organisations au sein de votre entreprise peuvent utiliser GitHub Actions, avec les options suivantes :

• Activer GitHub Actions pour toutes les organisations
• Activer GitHub Actions pour toutes les organisations
• Désactiver GitHub Actions pour toutes les organisations

Contrôle de l’accès aux actions publiques et workflows réutilisables

Les entreprises souhaitent souvent limiter l’accès à un groupe d’actions publiques bien testé et workflows réutilisables dans le cadre de leur gouvernance de la chaîne d’approvisionnement. Les stratégies disponibles dans GitHub vous permettent de contrôler l’accès sans bloquer les workflows dynamiques utilisés par code scanning et GitHub Code Quality.

Vous pouvez appliquer des contrôles stricts sans définir d’exceptions ou de configuration supplémentaire pour code scanning et GitHub Code Quality, avec les options suivantes :

• Autorisez toutes les actions et les flux de travail réutilisables  : toute action ou flux de travail réutilisable peut être utilisé, quel que soit l’auteur ou l’emplacement où il est défini.
• Autoriser les actions d’entreprise et flux de travail réutilisables  : seules les actions et flux de travail réutilisables définis dans un référentiel au sein de l’entreprise peuvent être utilisés. Bloque l’accès à toutes les actions créées par GitHub, telles que l’action actions/checkout.
• Autoriser les actions d’entreprise, les autres actions sélectionnées et les workflows réutilisables : toute action ou flux de travail réutilisable défini dans un référentiel au sein de l’entreprise peut être utilisé, ainsi que toute action ou flux de travail réutilisable qui correspond aux critères que vous spécifiez.
• Exiger que les actions soient associées à un SHA de commit complet : toutes les actions doivent être associées à un SHA de commit complet pour pouvoir être utilisées. Cela inclut les actions de votre entreprise et celles créées par GitHub. Les flux de travail réutilisables peuvent toujours être référencés par balise. Pour plus d’informations, consultez Informations de référence sur l’utilisation sécurisée.

Autoriser les actions d’entreprise, les autres actions sélectionnées et les workflows réutilisables

Si vous choisissez cette option, les actions et flux de travail réutilisables au sein de votre entreprise sont autorisés, et vous disposez des options suivantes pour autoriser d’autres actions et flux de travail réutilisables :

• Autoriser les actions créées par GitHub : autorise l’utilisation de toutes les actions créées par GitHub situées au sein des actions et github organisations.
• Autoriser les actions Marketplace par des créateurs vérifiés : permet l’utilisation de toutes les actions GitHub Marketplace publiées par des créateurs vérifiés et identifiées par .
• Autoriser ou bloquer les actions spécifiées et les flux de travail réutilisables : Autorise les actions et les flux de travail réutilisables que vous spécifiez. Vous pouvez spécifier des actions individuelles et workflows réutilisables ou des organisations et référentiels entiers.

Lorsque vous spécifiez des actions et des flux de travail réutilisables, utilisez la syntaxe suivante :

• Pour limiter l’accès à des étiquettes spécifiques ou valider des SHA d’une action ou un workflow réutilisable, utilisez la même syntaxe que celle utilisée dans le workflow pour sélectionner l’action ou un workflow réutilisable.
  • Pour une action, la syntaxe est OWNER/REPOSITORY@TAG-OR-SHA. Par exemple, utilisez actions/javascript-action@v1.0.1 pour sélectionner une étiquette ou actions/javascript-action@a824008085750b8e136effc585c3cd6082bd575f pour sélectionner un SHA.
  • Pour un workflow réutilisable, la syntaxe est OWNER/REPOSITORY/PATH/FILENAME@TAG-OR-SHA. Par exemple : octo-org/another-repo/.github/workflows/workflow.yml@v1.
• Pour spécifier un modèle, utiliser le caractère générique, *.
  • Pour autoriser toutes les actions et workflows réutilisables dans les organisations qui commencent par space-org, utilisez space-org*/*.
  • Pour autoriser toutes les actions et workflows réutilisables dans les dépôts qui commencent par octocat, utilisez */octocat**@*.
• Pour spécifier plusieurs modèles, utilisez , pour les séparer.
  • Pour autoriser toutes les actions et tous les flux de travail réutilisables des organisations octocat et octokit, utilisez octocat/*, octokit/*.
• Pour bloquer des modèles spécifiques, utilisez le préfixe !.
  • Pour autoriser toutes les actions et tous les flux de travail réutilisables de l’organisation space-org, mais bloquer une action spécifique telle que space-org/action, utilisez space-org/*, !space-org/action@*.
  • Par défaut, seules les actions et les flux de travail réutilisables spécifiés dans la liste seront autorisés. Pour autoriser toutes les actions et tous les flux de travail réutilisables tout en bloquant certaines actions spécifiques, utilisez *, !space-org/action@*.

Les stratégies ne restreignent jamais l'accès aux actions locales sur le système de fichiers de l'exécuteur (où le chemin d’accès uses: commence par ./).

Coureurs

Par défaut, toute personne disposant d’un accès administrateur à un dépôt peut ajouter un exécuteur auto-hébergé pour le référentiel et des exécuteurs auto-hébergé présentent des risques :

• Aucune garantie n’assure que les runners auto-hébergés s’exécutent sur des machines virtuelles éphémères et propres. Par conséquent, ils peuvent être compromis par du code non approuvé dans un workflow.
• Toute personne en mesure de créer une fourche du référentiel et d’ouvrir une demande de tirage peut compromettre l’environnement du runner auto-hébergé et potentiellement accéder aux secrets ainsi qu’au GITHUB_TOKEN, lesquels peuvent disposer d’un accès en écriture au référentiel.

Dans la section « Exécuteurs », vous pouvez atténuer ces risques en désactivant l’utilisation des exécuteurs hébergés par vos soins au niveau du référentiel.

• Désactiver pour toutes les organisations : empêche la création de runners au niveau du référentiel.
• Désactiver dans tous les référentiels UEM (Enterprise Managed User)  : empêche la création d’exécuteurs pour les référentiels détenus par comptes d’utilisateur managés.

Images personnalisées

Dans la section « Images personnalisées », vous pouvez contrôler quelles organisations de votre entreprise sont autorisées à créer et gérer des images personnalisées avec la stratégie d’accès suivante :

• Activer pour toutes les organisations : toutes les organisations, y compris celles créées à l’avenir, peuvent utiliser ou créer des images personnalisées.
• Activer pour des organisations spécifiques : seules les organisations sélectionnées peuvent utiliser ou créer des images personnalisées.
• Désactiver pour toutes les organisations : aucune organisation ne peut utiliser ou créer des images personnalisées.

Stratégies de rétention d’images personnalisées

Vous pouvez définir la durée pendant laquelle les versions d’image personnalisées sont conservées et quand elles deviennent inactives.

• Versions maximales par image : limite le nombre de versions de chaque image conservées. Lorsque cette limite est dépassée, les versions d’image inutilisées les plus anciennes sont automatiquement supprimées.
  • Valeur par défaut : 20 versions
  • Plage configurable : de 1 à 100 versions
• Rétention de version inutilisée : supprime les versions d’image qui n’ont pas été utilisées pendant un nombre spécifié de jours. Les versions d'image affectées à un pool de runners, mais qui ne sont pas utilisées activement, sont également considérées comme inutilisées.
  • Valeur par défaut : 30 jours
  • Plage configurable : 1 à 90 jours
• Âge maximal de la version : désactive les versions d’image créées avant le nombre de jours spécifié. Les versions d’images désactivées ne peuvent pas être utilisées par les runners tant que la limite définie par la stratégie n’a pas été augmentée.
  • Valeur par défaut : 60 jours
  • Plage configurable : 7 à 90 jours

Conservation des artefacts et des journaux d’activité

Par défaut, les artefacts et les fichiers journaux générés par les workflows sont conservés pendant 90 jours. Vous pouvez modifier la période de rétention.

• Pour les référentiels publics, vous pouvez configurer une période comprise entre 1 et 90 jours.
• Pour les référentiels privés et internes, vous pouvez configurer une période comprise entre 1 et 400 jours.

Les modifications ne s'appliquent qu'aux nouveaux artéfacts et fichiers journaux.

Paramètres du cache

Vous pouvez configurer des limites de rétention et de taille de cache maximales qui s’appliquent à l’ensemble de votre entreprise. Si vous augmentez la « limite d’éviction de taille du cache » au-delà des 10 Go inclus dans votre plan, vous serez facturé pour tout stockage supplémentaire d’entrées mises en cache.

Par défaut :

• Les caches sont conservés pendant 7 jours avant la suppression automatique.
• La limite totale de stockage du cache est de 10 Go par référentiel.

Vous pouvez personnaliser ces paramètres pour définir des limites maximales pour la rétention du cache et la taille de stockage du cache dans votre entreprise :

• Rétention du cache : configurez jusqu’à 90 jours pour les référentiels publics ou 365 jours pour les référentiels privés et internes.
• Limite d’éviction de taille du cache : configurez jusqu’à 10 000 Go par référentiel.

Les paramètres que vous configurez au niveau de l’entreprise agissent comme des limites maximales. Les propriétaires d’organisations peuvent choisir de configurer des limites pour leur organisation, mais ne peuvent pas dépasser les limites définies au niveau de l’entreprise. Les administrateurs de référentiels peuvent choisir de configurer des limites pour leurs référentiels, mais ne peuvent pas dépasser les limites définies au niveau de l’organisation.

Pour plus d’informations sur l’éviction du cache, consultez Référence sur la mise en cache des dépendances.

Workflows de demandes de tirage issues de forks provenant de collaborateurs externes

Tout le monde peut forker un dépôt public, puis soumettre une pull request pour proposer des modifications aux workflows du dépôt. Pour éviter les abus, les workflows ne s'exécutent pas automatiquement pour les pull requests créées par certains contributeurs.

Vous pouvez configurer les pull requests nécessitant une approbation avant d'être exécutées.

• Exiger l’approbation des nouveaux contributeurs découvrant GitHub. Rend l’approbation obligatoire pour les utilisateurs qui ne se sont jamais engagés dans ce référentiel et qui ont de nouveaux comptes GitHub.
• Exiger l’approbation pour les contributeurs pour la première fois. Rend l’approbation obligatoire pour les utilisateurs qui ne se sont jamais engagés dans ce référentiel
• Exiger l’approbation pour tous les collaborateurs externes. Rend l’approbation obligatoire pour tous les utilisateurs qui ne sont pas membres de l’organisation.

Forquer les workflows de pull request dans des référentiels privés

Vous pouvez contrôler la manière dont les utilisateurs peuvent exécuter des workflows sur des événements pull_request dans des référentiels privés et internes.

• Exécutez des workflows à partir de pull requests de fork. Les utilisateurs peuvent exécuter des workflows à partir de pull requests de fork. Par défaut, les workflows utilisent une autorisation en lecture seule GITHUB_TOKEN, sans accès aux secrets.
• Envoyez des jetons d’écriture aux workflows à partir des pull requests. Les flux de travail utiliseront un GITHUB_TOKEN avec autorisation d'écriture.
• Envoyer des secrets aux workflows depuis les demandes de tirage. Tous les secrets sont disponibles pour la pull request.
• Exiger une approbation pour les workflows de demande de tirage issus de forks. Les workflows exécutés sur des demandes de tirage provenant de collaborateurs ne disposant pas d’une autorisation d’écriture devront être approuvés par une personne possédant cette autorisation avant de pouvoir être lancés.

Si une stratégie est activée pour une entreprise, elle peut être désactivée de manière sélective dans des organisations ou dépôts individuels. Si une stratégie est désactivée pour une entreprise, les organisations ou les dépôts individuels ne peuvent pas l’activer.

Autorisations de workflow

Dans la section « Autorisations de workflows », vous pouvez définir les autorisations par défaut accordées au GITHUB_TOKEN.

• Autorisations de lecture et d’écriture : les autorisations par défaut pour le GITHUB_TOKEN dépendent de la date de création de l’entreprise ou de l’organisation :

  • Créé le 2 février 2023 ou après cette date – Par défaut, accès en lecture seule pour tous les périmètres.
  • Créé avant le 2 février 2023 : accès en lecture et en écriture par défaut pour toutes les étendues.

• Lire le contenu du référentiel et les autorisations des packages : par défaut, GITHUB_TOKEN dispose uniquement d’un accès en lecture pour les étendues contents et packages. Le paramètre plus permissif ne peut pas être choisi comme paramètre par défaut pour les organisations ou référentiels individuels.

Toute personne disposant d’un accès en écriture à un référentiel peut modifier les autorisations accordées au GITHUB_TOKEN pour un workflow spécifique, en modifiant la clé permissions dans le fichier de workflow.

          **L’autorisation permettant à GitHub Actions de créer et d’approuver des demandes de tirage** est disabled-by-default Si vous activez ce paramètre, `GITHUB_TOKEN` peut créer et approuver des demandes de tirage.