Skip to main content
Nous publions des mises à jour fréquentes de notre documentation, et la traduction de cette page peut encore être en cours. Pour obtenir les informations les plus actuelles, consultez la documentation anglaise.

Authentification par jeton automatique

GitHub fournit un jeton qui vous permet de vous authentifier au nom de GitHub Actions.

Remarque : Les exécuteurs hébergés sur GitHub ne sont pas pris en charge sur GitHub Enterprise Server. Vous pouvez voir plus d’informations sur le support futur planifié dans la GitHub public roadmap.

À propos du secret GITHUB_TOKEN

Au début de chaque exécution de workflow, GitHub crée automatiquement un secret GITHUB_TOKEN unique à utiliser dans votre workflow. Vous pouvez utiliser le secret GITHUB_TOKEN pour vous authentifier dans une exécution de workflow.

Lorsque vous activez GitHub Actions, GitHub installe une GitHub App sur votre dépôt. Le secret GITHUB_TOKEN est un jeton d’accès d’installation GitHub App. Vous pouvez utiliser le jeton d’accès d’installation pour vous authentifier au nom de GitHub App installée sur votre dépôt. Les autorisations du jeton sont limitées au dépôt qui contient votre workflow. Pour plus d’informations, consultez « Autorisations pour le GITHUB_TOKEN ».

Avant que chaque travail ne commence, GitHub récupère un jeton d’accès d’installation pour le travail. Le GITHUB_TOKEN expire à la fin d’un travail ou après un délai maximal de 24 heures.

Le jeton est également disponible dans le contexte github.token. Pour plus d’informations, consultez « Contextes ».

Utilisation de GITHUB_TOKEN dans un workflow

Vous pouvez utiliser le GITHUB_TOKEN avec la syntaxe standard pour référencer les secrets : ${{ secrets.GITHUB_TOKEN }}. Des exemples d’utilisation du GITHUB_TOKEN incluent la transmission du jeton en tant qu’entrée pour une action ou son utilisation pour créer une demande d’API GitHub Enterprise Server authentifiée.

Important : Une action peut accéder au GITHUB_TOKEN via le contexte github.token même si le workflow ne passe pas explicitement le GITHUB_TOKEN à l’action. En tant que bonne pratique de sécurité, vous devez toujours vous assurer que les actions ont uniquement l’accès minimal requis en limitant les autorisations accordées au GITHUB_TOKEN. Pour plus d’informations, consultez « Autorisations pour le GITHUB_TOKEN ».

Lorsque vous utilisez le GITHUB_TOKEN du dépôt pour effectuer des tâches, les événements déclenchés par le GITHUB_TOKEN ne créent pas de nouvelle exécution de workflow. Cela vous empêche de créer accidentellement des exécutions de workflow récursives. Par exemple, si une exécution de workflow pousse (push) du code à l’aide du GITHUB_TOKEN du dépôt, aucun nouveau workflow ne s’exécute même quand le dépôt contient un workflow configuré pour s’exécuter quand des événements push se produisent.

Exemple 1 : passage du GITHUB_TOKEN en tant qu’entrée

Cet exemple de workflow utilise l’action d’étiqueteur, qui nécessite GITHUB_TOKEN en tant que valeur du paramètre d’entrée repo-token :

YAML
name: Pull request labeler
on: [ pull_request_target ]

permissions:
  contents: read
  pull-requests: write

jobs:
  triage:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/labeler@v4
        with:
          repo-token: ${{ secrets.GITHUB_TOKEN }}

Exemple 2 : appel de l’API REST

Vous pouvez utiliser le GITHUB_TOKEN pour effectuer des appels d’API authentifiés. Cet exemple de workflow crée un problème à l’aide de l’API REST GitHub :

name: Create issue on commit

on: [ push ]

jobs:
  create_issue:
    runs-on: ubuntu-latest
    permissions:
      issues: write 
    steps:
      - name: Create issue using REST API
        run: |
          curl --request POST \
          --url http(s)://HOSTNAME/api/v3/repos/${{ github.repository }}/issues \
          --header 'authorization: Bearer ${{ secrets.GITHUB_TOKEN }}' \
          --header 'content-type: application/json' \
          --data '{
            "title": "Automated issue for commit: ${{ github.sha }}",
            "body": "This issue was automatically created by the GitHub Action workflow **${{ github.workflow }}**. \n\n The commit hash was: _${{ github.sha }}_."
            }' \
          --fail

Autorisations pour le GITHUB_TOKEN

Pour plus d’informations sur les points de terminaison d’API auxquels GitHub Apps peut accéder avec chaque autorisation, consultez « Autorisations GitHub App ».

Le tableau suivant montre les autorisations octroyées à GITHUB_TOKEN par défaut. Les personnes disposant d’autorisations d’administrateur sur une organisation ou un dépôt peuvent définir les autorisations par défaut comme étant permissives ou restreintes. Pour plus d’informations sur la définition des autorisations par défaut pour le GITHUB_TOKEN pour votre entreprise, organisation ou dépôt, consultez « Application de stratégies pour GitHub Actions dans votre entreprise », « Désactivation ou limitation de GitHub Actions pour votre organisation » ou « Gestion des paramètres de GitHub Actions pour un dépôt ».

ÉtendueAccès par défaut
(permissive)
Accès par défaut
(restreinte)
Accès maximal pour
demandes de tirage de
référentiels publics dupliqués[†]
actionslecture/écritureaucunlire
Vérificationslecture/écritureaucunlire
contenulecture/écriturelirelire
deploymentslecture/écritureaucunlire
problèmeslecture/écritureaucunlire
metadatalirelirelire
packageslecture/écritureaucunlire
pageslecture/écritureaucunlire
Demandes de tiragelecture/écritureaucunlire
repository-projectslecture/écritureaucunlire
security-eventslecture/écritureaucunlire
statuseslecture/écritureaucunlire

[†] Les référentiels privés peuvent contrôler si les demandes de tirage provenant des duplications peuvent exécuter des workflows et configurer les autorisations attribuées à GITHUB_TOKEN. Pour plus d’informations, consultez « Gestion des paramètres de GitHub Actions pour un référentiel ».

Modification des autorisations pour GITHUB_TOKEN

Vous pouvez modifier les autorisations pour GITHUB_TOKEN dans des fichiers de workflow individuels. Si les autorisations par défaut pour le GITHUB_TOKEN sont restrictives, vous devrez peut-être élever les autorisations pour permettre l’exécution de certaines actions et commandes. Si les autorisations par défaut sont permissives, vous pouvez modifier le fichier de workflow pour supprimer des autorisations du GITHUB_TOKEN. En guise de bonne pratique de sécurité, vous devez accorder à GITHUB_TOKEN le moins d’accès requis.

Vous pouvez voir les autorisations dont disposait GITHUB_TOKEN pour un travail spécifique dans la section « Configurer un travail » du journal d’exécution de workflow. Pour plus d’informations, consultez « Utilisation des journaux d’exécution de workflow ».

Vous pouvez utiliser la clé permissions dans votre fichier de workflow pour modifier les autorisations du GITHUB_TOKEN pour un workflow entier ou pour des travaux individuels. Cela vous permet de configurer les autorisations minimales requises pour un workflow ou un travail. Lorsque la clé permissions est utilisée, toutes les autorisations non spécifiées sont définies sur Aucun accès, à l’exception de l’étendue metadata, qui obtient toujours l’accès en lecture.

Vous pouvez utiliser la clé permissions afin d’ajouter et de supprimer des autorisations d’accès en lecture pour les dépôts dupliqués. Toutefois, en règle générale, vous ne pouvez pas octroyer d’accès en écriture. Il existe une exception à ce comportement. Il s’agit du moment où un utilisateur administrateur a sélectionné l’option Envoyer des jetons d’écriture aux workflows à partir des demandes de tirage dans les paramètres de GitHub Actions. Pour plus d’informations, consultez « Gestion des paramètres GitHub Actions pour un dépôt ».

Les deux exemples de workflows plus haut dans cet article montrent la clé permissions utilisée au niveau du workflow et au niveau du travail. Dans l’exemple 1, les deux autorisations sont spécifiées pour l’ensemble du workflow. Dans l’exemple 2, l’accès en écriture est accordé pour une étendue pour un seul travail.

Pour plus d’informations sur la clé permissions, consultez « Syntaxe de workflow pour GitHub Actions ».

Calcul des autorisations pour un travail de workflow

Les autorisations pour le GITHUB_TOKEN sont initialement définies sur le paramètre par défaut pour l’entreprise, l’organisation ou le dépôt. Si la valeur par défaut est définie sur les autorisations restreintes à l’un de ces niveaux, cela s’applique aux dépôts appropriés. Par exemple, si vous choisissez la valeur par défaut restreinte au niveau de l’organisation, tous les dépôts de cette organisation utiliseront les autorisations restreintes comme valeur par défaut. Les autorisations sont ensuite ajustées en fonction de n’importe quelle configuration dans le fichier de workflow, d’abord au niveau du workflow, puis au niveau du travail. Enfin, si le workflow a été déclenché par une demande de tirage à partir d’un dépôt dupliqué et que le paramètre Envoyer des jetons d’écriture aux workflows à partir des demandes de tirage n’est pas sélectionné, les autorisations sont ajustées pour remplacer les autorisations d’écriture par lecture seule.

Octroi d’autorisations supplémentaires

Si vous avez besoin d’un jeton qui nécessite des autorisations qui ne sont pas disponibles dans le GITHUB_TOKEN, vous pouvez créer un personal access token et le définir en tant que secret dans votre dépôt :

  1. Utilisez ou créez un jeton avec les autorisations appropriées pour ce dépôt. Pour plus d’informations, consultez « Création d’un personal access token ».
  2. Ajoutez le jeton en tant que secret dans le dépôt de votre workflow et faites-y référence à l’aide de la syntaxe ${{ secrets.SECRET_NAME }}. Pour plus d’informations, consultez « Création et utilisation de secrets chiffrés ».

Pour aller plus loin