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’organisations 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 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. 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 des organisations spécifiques
• Désactiver GitHub Actions pour toutes les organisations

Contrôle de l’accès aux actions

Les entreprises souhaitent souvent limiter l’accès à un groupe d’actions réutilisables bien testés 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 flux de travail dynamiques utilisés par code scanning et GitHub Code Quality.

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

• Autorisez toutes les actions réutilisables : n’importe quelle action réutilisable peut être utilisé, quel que soit l’auteur ou l’emplacement où il est défini.

• Autoriser les actions réutilisables : seules les actions réutilisables définis dans un référentiel au sein de l’entreprise peuvent être utilisés.

• Autoriser les actions sélectionnées: toute action réutilisable défini dans un référentiel au sein de l’entreprise peut être utilisé, ainsi que toute action 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 les actions créées par GitHub. Pour plus d’informations, consultez « Informations de référence sur l’utilisation sécurisée ».

Autoriser les actions sélectionnées

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

• Autoriser les actions créées par GitHub: Autorise toutes les actions créées par GitHub, situées dans les organisations actions et github.

• Autoriser les actions de la Place de marché par les créateurs vérifiés : Autorise toutes les actions créées par des GitHub Marketplace créateurs vérifiés, étiquetées avec .

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

• Autoriser ou bloquer les actions réutilisables : autorise les actions réutilisables que vous spécifiez. Vous pouvez spécifier des actions réutilisables ou des dépôts et des organisations entières.

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

• Pour restreindre l’accès à des étiquettes spécifiques ou valider des contrats SHA d’une action réutilisable, utilisez la même syntaxe que celle utilisée dans le flux de travail pour sélectionner l’action 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 spécifier un modèle, utiliser le caractère générique, *.
  • Pour autoriser toutes les actions réutilisables dans les organisations qui commencent par space-org, utilisez space-org*/*.
  • Pour autoriser toutes les actions réutilisables dans les référentiels qui commencent par octocat, utilisez */octocat**@*.
• Pour spécifier plusieurs modèles, utilisez , pour les séparer.
  • Pour autoriser toutes les actions 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 de l’organisation space-org , mais bloquer une action spécifique comme space-org/action, utilisez space-org/*, !space-org/action@*.
  • Par défaut, seules les actions réutilisables spécifiés dans la liste sont autorisés. Pour autoriser toutes les actions réutilisables tout en bloquant des 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ésactivation des exécuteurs hébergés standard

Vous pouvez désactiver les exécuteurs standard GitHubhébergés au niveau de l’entreprise. Ce paramètre nécessite des flux de travail pour cibler des exécuteurs par le biais de groupes d’exécuteurs et permet d’appliquer des contrôles d’accès et une gouvernance cohérents.

Pour plus d’informations sur les limites de concurrence des travaux pour GitHubles exécuteurs hébergés, consultez Limites d’Actions.

1. Dans le coin supérieur droit de GitHub Enterprise Server, cliquez sur votre photo de profil, puis sur Paramètres d’entreprise.
2. En haut de la page, cliquez sur Stratégies.
3. Sous «  Politiques », cliquez Actions.
4. Faites défiler jusqu’à la section « Exécuteurs hébergés standard », puis cliquez sur Désactiver pour toutes les organisations.
5. Cliquez sur Enregistrer.

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 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 n’importe où 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 volume total de cache utilisé par GitHub Actions sur l’espace de stockage externe pour votre instance GitHub Enterprise Server est limité à 10 Go maximum par dépôt.
• 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.