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.
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
| Utiliser 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
| Travailler avec des 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