Skip to main content

Secrets chiffrés

Les secrets chiffrés vous permettent de stocker des informations sensibles dans votre organisation, référentiel ou environnements de référentiel.

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 chiffrés

Les secrets sont des variables chiffrées 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 utilise une boîte scellée libsodium pour garantir que les secrets sont chiffrés avant qu’ils n’atteignent GitHub et restent chiffrés jusqu’à ce que vous les utilisiez 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 « Syntaxe de workflow pour GitHub Actions ».

Vous pouvez utiliser et lire des secrets chiffrés dans un fichier de workflow si vous avez accès à la modification du 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 « Secrets ».

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.

Remarque : Vous pouvez utiliser l’API REST pour gérer les secrets. Pour plus d’informations, consultez « API des secrets GitHub Actions ».

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

Pour créer des secrets pour un dépôt de compte personnel, vous devez être le propriétaire du dépôt. Pour créer des secrets pour un dépôt d’organisation, vous devez avoir l’accès admin.

  1. Dans your GitHub Enterprise Server instance, accédez à la page principale du dépôt. 1. Sous le nom de votre dépôt, cliquez sur Paramètres. Bouton Paramètres du dépôt 1. Dans la section « Sécurité » de la barre latérale, sélectionnez Secrets, , puis cliquez sur Actions.
  2. Cliquez sur Nouveau secret de dépôt.
  3. Tapez un nom pour votre secret dans la zone d’entrée Nom.
  4. Entrez la valeur de votre secret.
  5. 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 en savoir plus 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 chiffrés pour un environnement

Pour créer des secrets 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 pour un environnement dans un dépôt d’organisation, vous devez avoir l’accès admin.

  1. Dans your GitHub Enterprise Server instance, accédez à la page principale du dépôt. 1. Sous le nom de votre dépôt, cliquez sur Paramètres. Bouton Paramètres du dépôt 1. Dans la barre latérale gauche, cliquez sur Environnements.
  2. Cliquez sur l’environnement auquel vous souhaitez ajouter un secret.
  3. Sous Secrets d’environnement, cliquez sur Ajouter un secret.
  4. Tapez un nom pour votre secret dans la zone d’entrée Nom.
  5. Entrez la valeur de votre secret.
  6. 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 chiffrés 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.

Pour créer des secrets au niveau de l’organisation, vous devez avoir l’accès admin.

  1. Sur your GitHub Enterprise Server instance, accédez à la page principale de l’organisation. 1. Sous le nom de votre organisation, cliquez sur Paramètres. Bouton des paramètres de l’organisation 1. Dans la section « Sécurité » de la barre latérale, sélectionnez Secrets, , puis cliquez sur Actions.
  2. Cliquez sur Nouveau secret d’organisation.
  3. Tapez un nom pour votre secret dans la zone d’entrée Nom.
  4. Entrez la valeur de votre secret.
  5. Dans la liste déroulante Accès au dépôt, choisissez une stratégie d’accès.
  6. 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 your GitHub Enterprise Server instance, accédez à la page principale de l’organisation. 1. Sous le nom de votre organisation, cliquez sur Paramètres. Bouton des paramètres de l’organisation 1. Dans la section « Sécurité » de la barre latérale, sélectionnez Secrets, , puis cliquez sur Actions.
  2. La liste des secrets inclut toutes les autorisations et stratégies configurées. Par exemple : Liste des secrets
  3. Pour plus d’informations sur les autorisations configurées pour chaque secret, cliquez sur Mettre à jour.

Utilisation de secrets chiffrés dans un workflow

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 de 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 « Syntaxe de workflow pour 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 « Disponibilité du contexte » 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 chiffrés 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 encrypted 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.

    #!/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@v3
          - 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 « Limites pour les secrets ».

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 :

    $ base64 -i cert.der -o 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@v3
          - 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