Skip to main content

Cette version de GitHub Enterprise Server n'est plus disponible depuis le 2024-03-26. Aucune publication de correctifs n’est effectuée, même pour les problèmes de sécurité critiques. Pour de meilleures performances, une sécurité améliorée et de nouvelles fonctionnalités, effectuez une mise à niveau vers la dernière version de GitHub Enterprise. Pour obtenir de l’aide sur la mise à niveau, contactez le support GitHub Enterprise.

Utilisation de secrets dans GitHub Actions

Les secrets vous permettent de stocker des informations sensibles dans votre organisation, votre dépôt ou vos environnements de dépôt.

Tool navigation

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.

À propos des secrets

Les secrets sont des variables que vous créez dans une organisation, un dépôt ou un environnement de dépôt. Les secrets que vous créez sont disponibles pour être utilisés dans les workflows GitHub Actions. GitHub Actions peut lire un secret uniquement si vous l’incluez explicitement dans un workflow.

Pour les secrets stockés au niveau de l’organisation, vous pouvez utiliser des stratégies d’accès pour contrôler les référentiels pouvant utiliser les secrets de l’organisation. 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 stockés au niveau de l’environnement, vous pouvez permettre aux réviseurs nécessaires de 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.

Remarque : Si vos workflows GitHub Actions doivent accéder aux ressources d’un fournisseur de cloud qui prend en charge OpenID Connecter (OIDC), vous pouvez configurer vos workflows pour qu’ils s’authentifient directement auprès du fournisseur de cloud. Cela vous permet d’arrêter de stocker ces informations d’identification en tant que secrets de longue durée, et de fournir d’autres avantages en matière de sécurité. Pour plus d’informations, consultez « À propos du renforcement de la sécurité avec OpenID Connect ».

Nommage de vos secrets

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

  • Les noms peuvent contenir uniquement des caractères alphanumériques ([a-z], [A-Z], [0-9]) ou des traits de soulignement (_). Les espaces ne sont pas autorisés.

  • Les noms ne doivent pas commencer par le préfixe GITHUB_.

  • Les noms ne doivent pas commencer par un chiffre.

  • Les noms ne respectent pas la casse.

  • Les noms doivent être uniques au niveau où ils sont créés.

    Par exemple, un secret créé au niveau de l’environnement doit avoir un nom unique dans cet environnement, un secret créé au niveau du dépôt doit avoir un nom unique dans ce dépôt, et un secret créé au niveau de l’organisation doit avoir un nom unique à ce niveau.

    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.

Pour vous assurer que GitHub retire votre secret dans les journaux, évitez d’utiliser des données structurées comme valeurs de secrets. Par exemple, évitez de créer des secrets qui contiennent des objets blob JSON ou Git encodés.

Accès à vos secrets

Pour rendre un secret disponible pour une action, vous devez définir le secret en tant que variable d’entrée ou d’environnement dans le fichier de workflow. 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. Pour plus d’informations, consultez « Workflow syntax for GitHub Actions ».

Vous pouvez utiliser et lire des secrets dans un fichier de flux de travail si vous pouvez modifier le fichier. Pour plus d’informations, consultez « Autorisations d’accès sur GitHub ».

Avertissement : GitHub expurge automatiquement les secrets imprimés dans le journal, mais vous devez éviter d’imprimer intentionnellement des secrets dans le journal.

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.

Vous pouvez également gérer des secrets à l’aide de l’API REST. Pour plus d’informations, consultez « Points de terminaison REST pour l’API secrets GitHub Actions ».

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, sélectionnez le moins d’étendues nécessaires.

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. 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 ».

Remarque : les utilisateurs disposant d’un accès collaborateur à un référentiel peuvent utiliser l’API REST pour gérer les secrets de ce référentiel et les utilisateurs disposant d’un accès administrateur à une organisation peuvent utiliser l’API REST pour gérer les secrets de cette organisation. Pour plus d’informations, consultez « Points de terminaison REST pour l’API secrets GitHub Actions ».

Création de secrets pour un dépôt

Pour créer des secrets ou des variables sur GitHub pour un référentiel de compte personnel, vous devez être le propriétaire du référentiel. Pour créer des secrets ou des variables sur GitHub pour un référentiel d’une organisation, vous devez disposer d’un accès admin. Enfin, pour créer des secrets ou des variables pour un dépôt référentiel de personnel ou un référentiel d’organisation via l’API REST, vous devez disposer d’un accès collaborateur.

  1. Dans votre instance GitHub Enterprise Server, accédez à la page principale du dépôt.

  2. Sous le nom de votre dépôt, cliquez sur Paramètres. Si vous ne voyez pas l’onglet « Paramètres », sélectionnez le menu déroulant , puis cliquez sur Paramètres.

    Capture d’écran d’un en-tête de dépôt montrant les onglets. L’onglet « Paramètres » est mis en évidence avec un encadré orange foncé.

  3. Dans la section « Sécurité » de la barre latérale, sélectionnez Secrets et variables, puis cliquez sur Actions.

  4. Cliquez sur l’onglet Secrets. Capture d’écran de la page « Secrets et variables d’actions ».

  5. Cliquez sur Nouveau secret de dépôt.

  6. Dans le champ Nom, tapez un nom pour votre secret.

  7. Dans le champ Secret, entrez la valeur pour votre secret.

  8. Cliquez sur Ajouter un secret.

Si votre dépôt possède des secrets d’environnement ou peut accéder aux secrets de l’organisation parente, ces secrets sont également listés dans cette page.

Pour plus d’informations sur GitHub CLI, consultez « À propos de GitHub CLI ».

Pour ajouter un secret de dépôt, utilisez la sous-commande gh secret set. Remplacez secret-name par le nom de votre secret.

gh secret set SECRET_NAME

L’interface CLI vous invite à entrer une valeur secrète. Vous pouvez également lire la valeur du secret à partir d’un fichier.

gh secret set SECRET_NAME < secret.txt

Pour répertorier tous les secrets du dépôt, utilisez la sous-commande gh secret list.

Création de secrets pour un environnement

Pour créer des secrets ou des variables pour un environnement dans un dépôt de compte personnel, vous devez être le propriétaire du dépôt. Pour créer des secrets ou des variables pour un environnement dans un dépôt d’organisation, vous devez avoir l’accès admin. Pour plus d’informations sur les environnements, consultez « Utilisation d’environnements pour le déploiement ».

  1. Dans votre instance GitHub Enterprise Server, accédez à la page principale du dépôt.

  2. Sous le nom de votre dépôt, cliquez sur Paramètres. Si vous ne voyez pas l’onglet « Paramètres », sélectionnez le menu déroulant , puis cliquez sur Paramètres.

    Capture d’écran d’un en-tête de dépôt montrant les onglets. L’onglet « Paramètres » est mis en évidence avec un encadré orange foncé.

  3. Dans la barre latérale gauche, cliquez sur Environnements.

  4. Cliquez sur l’environnement auquel vous souhaitez ajouter un secret.

  5. Sous Secrets d’environnement, cliquez sur Ajouter un secret.

  6. Tapez un nom pour votre secret dans la zone d’entrée Nom.

  7. Entrez la valeur de votre secret.

  8. Cliquez sur Ajouter un secret.

Pour ajouter un secret pour un environnement, utilisez la sous-commande gh secret set avec l’indicateur --env ou -e suivi du nom de l’environnement.

gh secret set --env ENV_NAME SECRET_NAME

Pour répertorier tous les secrets pour un environnement, utilisez la sous-commande gh secret list avec l’indicateur --env ou -e suivi du nom de l’environnement.

gh secret list --env ENV_NAME

Création de secrets pour une organisation

Quand vous créez un secret ou une variable dans une organisation, vous pouvez utiliser une stratégie pour limiter l’accès par dépôt. Par exemple, vous pouvez accorder l’accès à tous les dépôts, ou limiter l’accès aux seuls dépôts privés ou à une liste spécifiée de dépôts.

Les propriétaires d’organisations peuvent créer des secrets ou des variables au niveau de l’organisation.

  1. Sur votre instance GitHub Enterprise Server, accédez à la page principale de l’organisation.

  2. Sous le nom de votre organisation, cliquez sur Paramètres. Si vous ne voyez pas l’onglet « Paramètres », sélectionnez le menu déroulant , puis cliquez sur Paramètres.

    Capture d’écran des onglets dans le profil d’une organisation. L’onglet « Paramètres » est présenté en orange foncé.

  3. Dans la section « Sécurité » de la barre latérale, sélectionnez Secrets et variables, puis cliquez sur Actions.

  4. Cliquez sur l’onglet Secrets.

    Capture d’écran de la page « Secrets et variables Actions ». Un onglet intitulé « Secrets » est encadré en orange foncé.

  5. Cliquez sur Nouveau secret d’organisation.

  6. Tapez un nom pour votre secret dans la zone d’entrée Nom.

  7. Entrez la valeur de votre secret.

  8. Dans la liste déroulante Accès au dépôt, choisissez une stratégie d’accès.

  9. Cliquez sur Ajouter un secret.

Remarque : Par défaut, GitHub CLI s’authentifie auprès des étendues repo et read:org. Pour gérer les secrets de l’organisation, vous devez également autoriser l’étendue admin:org.

gh auth login --scopes "admin:org"

Pour ajouter un secret pour une organisation, utilisez la sous-commande gh secret set avec l’indicateur --org ou -o suivi du nom de l’organisation.

gh secret set --org ORG_NAME SECRET_NAME

Par défaut, le secret est uniquement disponible pour les dépôts privés. Pour spécifier que le secret doit être disponible pour tous les dépôts au sein de l’organisation, utilisez l’indicateur --visibility ou -v.

gh secret set --org ORG_NAME SECRET_NAME --visibility all

Pour spécifier que le secret doit être disponible pour les dépôts sélectionnés au sein de l’organisation, utilisez l’indicateur --repos ou -r.

gh secret set --org ORG_NAME SECRET_NAME --repos REPO-NAME-1, REPO-NAME-2"

Pour répertorier tous les secrets pour une organisation, utilisez la sous-commande gh secret list avec l’indicateur --org ou -o suivi du nom de l’organisation.

gh secret list --org ORG_NAME

Examen de l’accès aux secrets au niveau de l’organisation

Vous pouvez vérifier quelles stratégies d’accès sont appliquées à un secret dans votre organisation.

  1. Sur votre instance GitHub Enterprise Server, accédez à la page principale de l’organisation.

  2. Sous le nom de votre organisation, cliquez sur Paramètres. Si vous ne voyez pas l’onglet « Paramètres », sélectionnez le menu déroulant , puis cliquez sur Paramètres.

    Capture d’écran des onglets dans le profil d’une organisation. L’onglet « Paramètres » est présenté en orange foncé.

  3. Dans la section « Sécurité » de la barre latérale, sélectionnez Secrets et variables, puis cliquez sur Actions.

  4. La liste des secrets inclut toutes les autorisations et stratégies configurées. Pour plus d’informations sur les autorisations configurées pour chaque secret, cliquez sur Mettre à jour.

Utilisation de secrets dans un flux de travail

Remarques :

  • À l’exception de GITHUB_TOKEN, les secrets ne sont pas transmis à l’exécuteur lorsqu’un workflow est déclenché à partir d’un référentiel dupliqué.

  • Les secrets ne sont pas transmis automatiquement aux workflows réutilisables. Pour plus d’informations, consultez « Réutilisation des workflows ».

Pour fournir une action avec un secret en tant que variable d’entrée ou d’environnement, vous pouvez utiliser le contexte secrets pour accéder aux secrets que vous avez créés dans votre dépôt. Pour plus d’informations, consultez « Contextes » et « Workflow syntax for GitHub Actions ».

steps:
  - name: Hello world action
    with: # Set the secret as an input
      super_secret: ${{ secrets.SuperSecret }}
    env: # Or as an environment variable
      super_secret: ${{ secrets.SuperSecret }}

Les secrets ne peuvent pas être directement référencés dans les conditions if:. Au lieu de cela, envisagez de définir des secrets en tant que variables d’environnement au niveau du travail, puis de référencer les variables d’environnement pour exécuter des étapes de manière conditionnelle dans le travail. Pour plus d’informations, consultez « Contextes » et jobs.<job_id>.steps[*].if.

Si un secret n’a pas été défini, la valeur de retour d’une expression référençant le secret (comme ${{ secrets.SuperSecret }} dans l’exemple) est une chaîne vide.

Évitez de passer des secrets entre les processus de la ligne de commande, dans la mesure du possible. Les processus de ligne de commande peuvent être visibles par d’autres utilisateurs (à l’aide de la commande ps) ou capturés par des événements d’audit de sécurité. Pour protéger les secrets, envisagez d’utiliser des variables d’environnement, STDIN ou d’autres mécanismes pris en charge par le processus cible.

Si vous devez passer des secrets dans une ligne de commande, placez-les entre guillemets conformément aux règles appropriées. Les secrets contiennent souvent des caractères spéciaux susceptibles d’affecter involontairement votre environnement. Pour placer ces caractères spéciaux dans une séquence d’échappement, utilisez des guillemets avec vos variables d’environnement. Par exemple :

Exemple d’utilisation de Bash

steps:
  - shell: bash
    env:
      SUPER_SECRET: ${{ secrets.SuperSecret }}
    run: |
      example-command "$SUPER_SECRET"

Exemple d’utilisation de PowerShell

steps:
  - shell: pwsh
    env:
      SUPER_SECRET: ${{ secrets.SuperSecret }}
    run: |
      example-command "$env:SUPER_SECRET"

Exemple d’utilisation de Cmd.exe

steps:
  - shell: cmd
    env:
      SUPER_SECRET: ${{ secrets.SuperSecret }}
    run: |
      example-command "%SUPER_SECRET%"

Limites pour les secrets

Vous pouvez stocker jusqu’à 1 000 secrets d’organisation, 100 secrets de dépôt et 100 secrets d’environnement.

Un workflow créé dans un dépôt peut accéder au nombre de secrets suivant :

  • Les 100 secrets du dépôt.
  • Si le dépôt a accès à plus de 100 secrets d’organisation, le workflow ne peut utiliser que les 100 premiers secrets d’organisation (triés par ordre alphabétique par nom de secret).
  • Les 100 secrets d’environnement.

La taille des secrets est limitée à 48 ko. Pour stocker des secrets plus volumineux, consultez la solution de contournement « Stockage de secrets volumineux » ci-dessous.

Stockage de secrets volumineux

Pour utiliser des secrets avec une taille supérieure à 48 Ko, vous pouvez utiliser une solution de contournement pour stocker les secrets dans votre référentiel et enregistrer la phrase secrète de déchiffrement sous la forme d’un secret sur GitHub. Par exemple, vous pouvez utiliser gpg pour chiffrer un fichier contenant votre secret localement avant de vérifier le fichier chiffré dans votre référentiel sur GitHub. Pour plus d’informations, consultez « gpg manpage ».

Avertissement : veillez à ce que vos secrets ne soient pas imprimés lorsque votre workflow s’exécute. Lorsque vous utilisez cette solution de contournement, GitHub ne retire pas les secrets imprimés dans les journaux.

  1. Exécutez la commande suivante à partir de votre terminal pour chiffrer le fichier contenant votre secret avec gpg et l’algorithme de chiffrement AES256. Dans cet exemple, my_secret.json est le fichier contenant le secret.

    gpg --symmetric --cipher-algo AES256 my_secret.json
    
  2. Vous serez invité à entrer une phrase secrète. Mémorisez la phrase secrète, car vous devrez créer un secret sur GitHub qui utilise la phrase secrète comme valeur.

  3. Créez un secret qui contient la phrase secrète. Par exemple, créez un secret avec le nom LARGE_SECRET_PASSPHRASE et définissez la valeur du secret sur la phrase secrète utilisée à l’étape ci-dessus.

  4. Copiez votre fichier chiffré sur un chemin d’accès dans votre référentiel et validez-le. Dans cet exemple, le fichier chiffré est my_secret.json.gpg.

    Avertissement : veillez à copier le fichier chiffré my_secret.json.gpg se terminant par l’extension de fichier .gpg et non le fichier non chiffré my_secret.json.

    git add my_secret.json.gpg
    git commit -m "Add new secret JSON file"
    
  5. Créez un script d’interpréteur de commandes dans votre référentiel pour déchiffrer le fichier secret. Dans cet exemple, le script est nommé decrypt_secret.sh.

    Shell
    #!/bin/sh
    
    # Decrypt the file
    mkdir $HOME/secrets
    # --batch to prevent interactive command
    # --yes to assume "yes" for questions
    gpg --quiet --batch --yes --decrypt --passphrase="$LARGE_SECRET_PASSPHRASE" \
    --output $HOME/secrets/my_secret.json my_secret.json.gpg
    
  6. Vérifiez que votre script shell est exécutable avant de l’archiver dans votre dépôt.

    chmod +x decrypt_secret.sh
    git add decrypt_secret.sh
    git commit -m "Add new decryption script"
    git push
    
  7. Dans votre workflow GitHub Actions, utilisez un step pour appeler le script d’interpréteur de commandes et déchiffrer le secret. Pour avoir une copie de votre dépôt dans l’environnement dans lequel votre workflow s’exécute, vous devez utiliser l’action actions/checkout. Référencez votre script shell à l’aide de la commande run relative à la racine de votre dépôt.

    name: Workflows with large secrets
    
    on: push
    
    jobs:
      my-job:
        name: My Job
        runs-on: ubuntu-latest
        steps:
          - uses: actions/checkout@v4
          - name: Decrypt large secret
            run: ./decrypt_secret.sh
            env:
              LARGE_SECRET_PASSPHRASE: ${{ secrets.LARGE_SECRET_PASSPHRASE }}
          # This command is just an example to show your secret being printed
          # Ensure you remove any print statements of your secrets. GitHub does
          # not hide secrets that use this workaround.
          - name: Test printing your secret (Remove this step in production)
            run: cat $HOME/secrets/my_secret.json
    

Stockage d’objets blob binaires Base64 en tant que secrets

Vous pouvez utiliser l’encodage Base64 pour stocker de petits objets blob binaires en tant que secrets. Vous pouvez ensuite référencer le secret dans votre workflow et le décoder pour une utilisation sur l’exécuteur. Pour connaître les limites de taille, consultez « Utilisation de secrets dans GitHub Actions ».

Remarque : Notez que Base64 convertit uniquement le binaire en texte et n’est pas un substitut pour le chiffrement réel.

  1. Utilisez base64 pour encoder votre fichier en une chaîne Base64. Par exemple :

    Sur macOS, vous pouvez exécuter :

    base64 -i cert.der -o cert.base64
    

    Sur Linux, vous pouvez exécuter :

    base64 -w 0 cert.der > cert.base64
    
  2. Créez un secret qui contient la chaîne Base64. Par exemple :

    $ gh secret set CERTIFICATE_BASE64 < cert.base64
    ✓ Set secret CERTIFICATE_BASE64 for octocat/octorepo
    
  3. Pour accéder à la chaîne Base64 à partir de votre exécuteur, dirigez le secret vers base64 --decode. Par exemple :

    name: Retrieve Base64 secret
    on:
      push:
        branches: [ octo-branch ]
    jobs:
      decode-secret:
        runs-on: ubuntu-latest
        steps:
          - uses: actions/checkout@v4
          - name: Retrieve the secret and decode it to a file
            env:
              CERTIFICATE_BASE64: ${{ secrets.CERTIFICATE_BASE64 }}
            run: |
              echo $CERTIFICATE_BASE64 | base64 --decode > cert.der
          - name: Show certificate information
            run: |
              openssl x509 -in cert.der -inform DER -text -noout
    

Remarque : L’utilisation d’un autre interpréteur de commandes peut nécessiter des commandes différentes pour décoder le secret dans un fichier. Sur les exécuteurs Windows, nous vous recommandons d’utiliser un interpréteur de commandes bash avec shell: bash pour utiliser les commandes de l’étape run ci-dessus.

Retrait des secrets à partir des journaux d’exécution de workflow

Alors que GitHub retire automatiquement les secrets imprimés dans les journaux d’exécution de workflow, les exécuteurs ne peuvent supprimer que les secrets auxquels ils ont accès. Cela signifie qu’un secret sera retiré uniquement s’il a été utilisé dans un projet. En guise de mesure de sécurité, vous pouvez supprimer les journaux d’exécution de workflow pour empêcher la fuite de valeurs sensibles. Pour plus d’informations, consultez « Using workflow run logs ».