About secrets
Secrets allow you to store sensitive information in your organization, repository, or repository environments. Secrets are variables that you create to use in GitHub Actions workflows in an organization, repository, or repository environment.
GitHub Actions can only read a secret if you explicitly include the secret in a workflow.
Naming your secrets
Conseil
To help ensure that GitHub redacts your secrets in logs correctly, avoid using structured data as the values of secrets.
The following rules apply to secret names:
- Peuvent uniquement contenir des caractères alphanumériques (
[a-z],[A-Z],[0-9]) ou des traits de soulignement (_). Les espaces ne sont pas autorisés. - Ne doit pas commencer par le préfixe
GITHUB_. - Ne doit pas commencer par un chiffre.
- Ne sont pas sensibles à la casse lorsqu’ils sont référencés. GitHub enregistre les noms de secrets en majuscules, quelle que soit la façon dont ils sont entrés.
- Doivent être uniques au référentiel, à l’organisation ou à l’entreprise où ils sont créés.
S’il existe un secret du même nom à plusieurs niveaux, le secret au niveau le plus bas est prioritaire. Par exemple, si un secret au niveau de l’organisation porte le même nom qu’un secret au niveau du dépôt, celui-ci est prioritaire. Similarly, if an organization, repository, and environment all have a secret with the same name, the environment-level secret takes precedence.
Using your secrets in workflows
Avertissement
Si un secret est utilisé dans une tâche de flux de travail, GitHub masque automatiquement les secrets imprimés dans le journal. Vous devez éviter d’imprimer intentionnellement des secrets dans le journal d’activité.
Les secrets au niveau de l’organisation vous permettent de partager des secrets entre plusieurs référentiels, ce qui réduit la nécessité de créer des secrets en double. La mise à jour d’un secret d’organisation dans un emplacement garantit également que la modification prend effet dans tous les workflows de référentiel qui utilisent ce secret.
For environment secrets, you can enable required reviewers to control access to the secrets. A workflow job cannot access environment secrets until approval is granted by required approvers.
To make a secret available to an action, you must set the secret as an input or environment variable in your workflow file. Review the action's README file to learn about which inputs and environment variables the action expects. See Workflow syntax for GitHub Actions.
Organization and repository secrets are read when a workflow run is queued, and environment secrets are read when a job referencing the environment starts.
Limiting credential permissions
When generating credentials, we recommend that you grant the minimum permissions possible. For example, instead of using personal credentials, use deploy keys or a service account. Consider granting read-only permissions if that's all that is needed, and limit access as much as possible.
When generating a personal access token (classic), select the fewest scopes necessary. When generating a fine-grained personal access token, select the minimum permissions and repository access required.
Instead of using a personal access token, consider using a GitHub App, which uses fine-grained permissions and short lived tokens, similar to a fine-grained personal access token. Unlike a personal access token, a GitHub App is not tied to a user, so the workflow will continue to work even if the user who installed the app leaves your organization. For more information, see Effectuer des requêtes d’API authentifiées avec une application GitHub dans un workflow GitHub Actions.