Contrôle des autorisations pour GITHUB_TOKEN

Vue d’ensemble

Vous pouvez utiliser permissions pour modifier les autorisations par défaut octroyées à GITHUB_TOKEN, en ajoutant ou en supprimant l’accès selon les besoins, afin d’autoriser uniquement l’accès minimal nécessaire. Pour plus d’informations, consultez « Authentification par jeton automatique ».

Vous pouvez utiliser permissions en tant que clé de niveau supérieur, à appliquer à tous les travaux du workflow ou à des travaux spécifiques. Quand vous ajoutez la clé permissions à un travail spécifique, toutes les actions et commandes d’exécution de ce travail qui utilisent GITHUB_TOKEN obtiennent les droits d’accès que vous spécifiez. Pour plus d’informations, consultez jobs.<job_id>.permissions.

Pour chacune des autorisations disponibles, indiquées sur la table ci-dessous, vous pouvez attribuer l’un des niveaux d’accès : read (le cas échéant), write ou none. write comprend read. Si vous spécifiez l’accès pour l’une de ces autorisations, toutes celles qui ne sont pas spécifiées sont définies sur none.

Autorisations disponibles et détails de ce que chacune permet à une action d’effectuer :

Autorisation	Autorise une action à l’aide de GITHUB_TOKEN à
actions	Utilisez GitHub Actions. Par exemple, actions: write permet à une action d’annuler l’exécution d’un workflow. Pour plus d’informations, consultez « Autorisations requises pour les applications GitHub ».
checks	Utilisez des exécutions de vérifications et des suites de vérifications. Par exemple, checks: write permet à une action de créer l’exécution d’une vérification. Pour plus d’informations, consultez « Autorisations requises pour les applications GitHub ».
contents	Utilisez le contenu du référentiel. Par exemple, contents: read autorise une action à répertorier les validations et contents: write autorise l’action à créer une mise en production. Pour plus d’informations, consultez « Autorisations requises pour les applications GitHub ».
deployments	Utilisez des déploiements. Par exemple, deployments: write permet à une action de créer un nouveau déploiement. Pour plus d’informations, consultez « Autorisations requises pour les applications GitHub ».
discussions	Travaillez avec les discussions GitHub. Par exemple, discussions: write permet à une action de fermer ou de supprimer une discussion. Pour plus d’informations, consultez « Utilisation de l’API GraphQL pour les discussions ».
issues	Travaillez avec les problèmes. Par exemple, issues: write permet à une action d’ajouter un commentaire à un problème. Pour plus d’informations, consultez « Autorisations requises pour les applications GitHub ».
packages	Utiliser des packages GitHub. Par exemple, packages: write permet à une action de charger et de publier des packages sur des packages GitHub. Pour plus d’informations, consultez « À propos des autorisations pour les packages GitHub ».
pages	Utiliser des pages GitHub. Par exemple, pages: write autorise une action à demander une build GitHub Pages. Pour plus d’informations, consultez « Autorisations requises pour les applications GitHub ».
pull-requests	Utiliser des demandes de tirage. Par exemple, pull-requests: write permet à une action d’ajouter une étiquette à une demande de tirage. Pour plus d’informations, consultez « Autorisations requises pour les applications GitHub ».
repository-projects	Utiliser des projets GitHub (classique). Par exemple, repository-projects: write permet à une action d’ajouter une colonne à un projet (classique). Pour plus d’informations, consultez « Autorisations requises pour les applications GitHub ».
security-events	Utiliser l’analyse du code GitHub et les alertes Dependabot. Par exemple, security-events: read permet à une action de répertorier les alertes Dependabot pour le référentiel et security-events: write permet à une action de mettre à jour l’état d’une alerte d’analyse du code. Pour plus d’informations, consultez « Autorisations de référentiel pour les « alertes d’analyse du code » » et « Autorisations de référentiel pour les « alertes Dependabot » » dans « Autorisations requises pour les applications GitHub ».
statuses	Utiliser les états de validation. Par exemple, statuses:read autorise une action à répertorier les états de validation pour une référence donnée. Pour plus d’informations, consultez « Autorisations requises pour les applications GitHub ».

Définition de l’accès pour les autorisations GITHUB_TOKEN

Vous pouvez définir l’accès que le GITHUB_TOKEN autorise en spécifiant read, write ou none comme valeur des autorisations disponibles dans la clé permissions.

permissions:
  actions: read|write|none
  checks: read|write|none
  contents: read|write|none
  deployments: read|write|none
  issues: read|write|none
  discussions: read|write|none
  packages: read|write|none
  pages: read|write|none
  pull-requests: read|write|none
  repository-projects: read|write|none
  security-events: read|write|none
  statuses: read|write|none

Si vous spécifiez l’accès pour l’une de ces autorisations, toutes celles qui ne sont pas spécifiées sont définies sur none.

Vous pouvez utiliser la syntaxe suivante pour définir l'un des accès read-all ou write-all à toutes les autorisations disponibles :

permissions: read-all

permissions: write-all

Vous pouvez utiliser la syntaxe suivante afin de désactiver les autorisations pour toutes les autorisations disponibles :

permissions: {}

Modification des autorisations dans un référentiel dupliqué

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 de GitHub Actions pour un dépôt ».

Définition des autorisations GITHUB_TOKEN pour tous les travaux d’un workflow

Vous pouvez spécifier permissions au niveau supérieur d’un workflow, afin que le paramètre s’applique à tous les travaux du workflow.

Exemple : définition des autorisations GITHUB_TOKEN pour un workflow entier

Cet exemple montre les autorisations définies pour GITHUB_TOKEN, qui s’appliquent à tous les travaux du workflow. Toutes les autorisations se voient octroyer un accès en lecture.

name: "My workflow"

on: [ push ]

permissions: read-all

jobs:
  ...

Définition des autorisations GITHUB_TOKEN pour un travail spécifique

Pour un travail spécifique, vous pouvez utiliser jobs.<job_id>.permissions afin de modifier les autorisations par défaut octroyées à GITHUB_TOKEN, en ajoutant ou en supprimant l’accès selon les besoins, afin d’autoriser uniquement l’accès minimal nécessaire. Pour plus d’informations, consultez « Authentification par jeton automatique ».

En spécifiant l’autorisation dans une définition de travail, vous pouvez configurer un ensemble d’autorisations différent pour le GITHUB_TOKEN de chaque travail, le cas échéant. Vous pouvez également spécifier les autorisations relatives à tous les travaux du workflow. Pour plus d’informations sur la définition d’autorisations au niveau du workflow, consultez permissions.

Exemple : définition des autorisations GITHUB_TOKEN pour un travail dans un workflow

Cet exemple montre les autorisations définies pour GITHUB_TOKEN, qui s’appliquent uniquement au travail nommé stale. L’accès en écriture est octroyé pour les autorisations issues et pull-requests. Toutes les autres autorisations n’ont aucun accès.

jobs:
  stale:
    runs-on: ubuntu-latest

    permissions:
      issues: write
      pull-requests: write

    steps:
      - uses: actions/stale@v5