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. Dans le coin supérieur droit de GitHub Enterprise Server, cliquez sur votre photo de profil, puis sur Paramètres d’entreprise.
2. Sur le côté gauche de la page, dans la barre latérale du compte d’entreprise, 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

Les entreprises souhaitent souvent limiter l’accès à un groupe d’actions publiques bien testé 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 **  : toute action peut être utilisé, quel que soit l’auteur ou l’emplacement où il est défini.
• **Autoriser les actions d’entreprise **  : seules les actions définis dans un référentiel au sein de l’entreprise peuvent être utilisés.
• Autoriser les actions sélectionnées : toute action défini dans un référentiel au sein de l’entreprise peut être utilisé, ainsi que toute action qui correspond aux critères que vous spécifiez.

Autoriser les actions sélectionnées

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

• 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 .

  Uniquement disponible si vous avez activé et configuré GitHub Connect avec GitHub Actions. Consultez Activation de l’accès automatique aux actions de GitHub.com à l’aide de GitHub Connect.

• Autoriser les actions spécifiées : Autorise les actions que vous spécifiez. Vous pouvez spécifier des actions individuelles ou des organisations et référentiels entiers.

Lorsque vous spécifiez des actions, utilisez la syntaxe suivante :

• Pour limiter l’accès à des étiquettes spécifiques ou valider des SHA d’une action, utilisez la même syntaxe que celle utilisée dans le workflow pour sélectionner l’action.
  • 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 spécifier un modèle, utiliser le caractère générique, *.
  • Pour autoriser toutes les actions dans les organisations qui commencent par space-org, utilisez space-org*/*.
  • Pour autoriser toutes les actions 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 des organisations octocat et octokit, utilisez octocat/*, octokit/*.

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.

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

Paramètres des artefacts, des journaux d’activité et du cache

Ces stratégies contrôlent le stockage des artefacts, des journaux et des caches.

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 remplacer cette période de rétention par un chiffre cpmpris entre 1 et 400 jours.

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

Limites de taille maximale et de cache par défaut

Par défaut :

• Le stockage total du cache que GitHub Actions utilise sur le stockage externe pour votre instance GitHub Enterprise Server est limité à un maximum de 10 Go par référentiel.
• La taille maximale autorisée pouvant être définie pour un référentiel est de 25 Go.

Si vous dépassez la limite, GitHub enregistrera le nouveau cache, mais commencera à écarter les caches jusqu’à ce que la taille totale soit inférieure à la limite du dépôt.

Vous pouvez personnaliser la taille totale par défaut du cache pour chaque référentiel, ainsi que la taille totale maximale du cache autorisée pour un référentiel. Par exemple, vous pourriez souhaiter que la taille totale par défaut du cache pour chaque référentiel soit de 5 Go, tout en permettant aux administrateurs du référentiel de configurer une taille totale de cache jusqu’à 15 Go pour des référentiels individuels.

Les propriétaires d'organisations peuvent définir une taille de cache totale inférieure qui s'applique à chaque référentiel de leur organisation. Les personnes disposant d'un accès administrateur à un référentiel peuvent définir une taille totale de cache pour leur référentiel jusqu'à la taille maximale de cache autorisée par la politique de l'entreprise ou 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.