À propos des secrets

À propos des secrets

Les secrets vous permettent de stocker des informations sensibles dans votre organisation, votre référentiel ou votre environnement de référentiel. Les secrets sont des variables que vous créez pour les utiliser dans les flux de travail GitHub Actions d’une organisation, d’un référentiel ou d’un environnement de référentiel.

GitHub Actions peut lire un secret uniquement si vous l’incluez explicitement dans un workflow.

Nommage de vos secrets

Les règles suivantes s’appliquent aux noms de secrets :

• 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 respectent pas la casse.
• 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. De même, si une organisation, un dépôt et un environnement ont tous un secret portant le même nom, le secret au niveau de l’environnement est prioritaire.

Utilisation de vos secrets dans les flux de travail

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.

Pour les secrets d’environnement, vous pouvez autoriser les réviseurs requis à contrôler l’accès aux secrets. Un travail de workflow ne peut pas accéder aux secrets d’environnement tant que l’approbation n’est pas accordée par les réviseurs nécessaires.

Afin de rendre un secret disponible pour une action, vous devez définir le secret en tant que variable d’entrée ou d’environnement dans votre fichier de flux de travail. Passez en revue le fichier README de l’action pour en savoir plus sur les entrées et variables d’environnement attendues par l’action. Consultez Workflow syntax for GitHub Actions.

Les secrets de l’organisation et du dépôt sont lus quand une exécution de workflow est mise en file d’attente, et les secrets de l’environnement sont lus quand un travail référençant l’environnement démarre.

Limitation des autorisations d’informations d’identification

Lors de la génération d’informations d’identification, nous vous recommandons d’accorder les autorisations minimales possibles. Par exemple, au lieu d’utiliser des informations d’identification personnelles, utilisez des clés de déploiement ou un compte de service. Envisagez d’accorder des autorisations en lecture seule si cela suffit et limitez l’accès autant que possible.

Lors de la génération d’un personal access token (classic), sélectionnez aussi peu d’étendues que nécessaire. Lors de la génération d’un fine-grained personal access token, sélectionnez les autorisations et l’accès au dépôt minimaux requis.

Au lieu d’utiliser un personal access token, envisagez d’utiliser une GitHub App, qui utilise des autorisations affinées et des jetons de courte durée, comme un fine-grained personal access token. Contrairement à un personal access token, une GitHub App n’est pas liée à un utilisateur ; ainsi, le workflow continue de fonctionner même si l’utilisateur qui a installé l’application quitte votre organisation. Pour plus d’informations, consultez « Effectuer des requêtes d’API authentifiées avec une application GitHub dans un workflow GitHub Actions ».

Pour aller plus loin

• Utilisation de secrets dans GitHub Actions
• Points de terminaison REST pour l’API secrets GitHub Actions