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 ». |
attestations | Utilisez des attestations d’artefact. Par exemple, attestations: write autorise une action à générer une attestation d’artefact pour un build. Pour plus d’informations, consultez « Utilisation d’attestations d’artefact pour établir la provenance des builds ». |
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 ». |
id-token | Récupérez un jeton OpenID Connect (OIDC). Cela nécessite id-token: write. Pour plus d’informations, consultez « À propos du renforcement de la sécurité avec OpenID Connect ». |
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
attestations: read|write|none
checks: read|write|none
contents: read|write|none
deployments: read|write|none
id-token: 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