Récupérer dynamiquement le secret des actions GitHub

Mise à jour - août 2020

Suite à une expérience pratique avec ce projet terraform-monorepo , voici un exemple de la façon dont j'ai réussi à utiliser des noms secrets de manière dynamique

1. Les noms des secrets sont alignés sur les noms d'environnements et les noms de branches - development , staging et production
2. $GITHUB_REF_SLUG provient de l' action Slug GitHub qui récupère le nom de la branche
3. Les commandes qui effectuent l'analyse sont

env:
  SECRET_PREFIX: A
  SECRET_NAME: ${{ env.SECRET_PREFIX }}_FRUIT_NAME

Exemple complet

SECRET_NAME = A_FRUIT_NAME
SECRET_NAME = A_FRUIT_NAME
SECRET_VALUE = ***

Après avoir lu ceci - Syntaxe de contexte et d'expression pour les actions GitHub , en me concentrant sur l' objet env , j'ai découvert que:

Dans le cadre d'une expression, vous pouvez accéder aux informations de contexte en utilisant l'une des deux syntaxes.

Syntaxe de l'index: github ['sha']

Syntaxe de déréférencement de propriété: github.sha

Donc, le même comportement s'applique aux secrets , vous pouvez faire des secrets[secret_name] , donc vous pouvez faire ce qui suit

    - name: Run a multi-line script
      env:
        SECRET_NAME: A_FRUIT_NAME
      run: |
        echo "SECRET_NAME = $SECRET_NAME"
        echo "SECRET_NAME = ${{ env.SECRET_NAME }}"
        SECRET_VALUE=${{ secrets[env.SECRET_NAME] }}
        echo "SECRET_VALUE = $SECRET_VALUE"

Ce qui aboutit à

name: pipeline

on:
  push:
    branches: [development, staging, production]
    paths-ignore:
      - "README.md"

jobs:
  terraform:
    runs-on: ubuntu-latest

    env:
      ### -----------------------
      ### Available in all steps, change app_name to your app_name
      TF_VAR_app_name: tfmonorepo
      ### -----------------------

    steps:
      - uses: actions/checkout@v2
      - name: Inject slug/short variables
        uses: rlespinasse/github-slug-action@v2.x
      - name: prepare-files-folders
        run: |
          mkdir -p ${GITHUB_REF_SLUG}/
          cp live/*.${GITHUB_REF_SLUG} ${GITHUB_REF_SLUG}/
          cp live/*.tf ${GITHUB_REF_SLUG}/
          cp live/*.tpl ${GITHUB_REF_SLUG}/ 2>/dev/null || true
          mv ${GITHUB_REF_SLUG}/backend.tf.${GITHUB_REF_SLUG} ${GITHUB_REF_SLUG}/backend.tf
      - name: install-terraform
        uses: little-core-labs/install-terraform@v1
        with:
          version: 0.12.28
      - name: set-aws-credentials
        run: |
          echo "::set-env name=AWS_ACCESS_KEY_ID_SECRET_NAME::AWS_ACCESS_KEY_ID_${GITHUB_REF_SLUG}"
          echo "::set-env name=AWS_SECRET_ACCESS_KEY_SECRET_NAME::AWS_SECRET_ACCESS_KEY_${GITHUB_REF_SLUG}"
      - name: terraform-apply
        run: |
          export AWS_ACCESS_KEY_ID=${{ secrets[env.AWS_ACCESS_KEY_ID_SECRET_NAME] }}
          export AWS_SECRET_ACCESS_KEY=${{ secrets[env.AWS_SECRET_ACCESS_KEY_SECRET_NAME] }}
          cd ${GITHUB_REF_SLUG}/
          terraform version
          rm -rf .terraform
          terraform init -input=false
          terraform get
          terraform validate
          terraform plan -out=plan.tfout -var environment=${GITHUB_REF_SLUG}
          terraform apply -auto-approve plan.tfout 
          rm -rf .terraform

Puisque SECRET_VALUE est expurgé, nous pouvons supposer que le vrai secret a été récupéré.

Les choses que j'ai apprises -

1. Vous ne pouvez pas référencer env partir d'un autre env , donc cela ne fonctionnera pas

         - name: set-aws-credentials
           run: |
             echo "::set-env name=AWS_ACCESS_KEY_ID_SECRET_NAME::AWS_ACCESS_KEY_ID_${GITHUB_REF_SLUG}"
             echo "::set-env name=AWS_SECRET_ACCESS_KEY_SECRET_NAME::AWS_SECRET_ACCESS_KEY_${GITHUB_REF_SLUG}"
         - name: terraform-apply
           run: |
             export AWS_ACCESS_KEY_ID=${{ secrets[env.AWS_ACCESS_KEY_ID_SECRET_NAME] }}
             export AWS_SECRET_ACCESS_KEY=${{ secrets[env.AWS_SECRET_ACCESS_KEY_SECRET_NAME] }}
   

   Le résultat de SECRET_NAME est _FRUIT_NAME , pas bon

2. Vous pouvez utiliser des expressions de contexte dans votre code, pas seulement dans env , vous pouvez le voir dans SECRET_VALUE=${{ secrets[env.SECRET_NAME] }} , ce qui est cool

Et bien sûr - voici le flux de travail que j'ai testé - https://github.com/unfor19/gha-play/runs/595345435?check_suite_focus=true - cochez l'action Run a multi-line script

J'ai pu y parvenir en utilisant le nom du workflow comme variable spécifique à la branche.

Pour chaque branche que je crée, je mets simplement à jour cette valeur unique en haut du fichier YML, puis j'ajoute GitHub Secrets pour correspondre au nom du workflow:

name: CUSTOMER1

jobs:
  build:
    runs-on: ubuntu-latest
    env:
      AWS_ACCESS_KEY_ID: ${{ github.workflow }}_AWS_ACCESS_KEY_ID
    steps:
    - uses: actions/checkout@v2
    - run: echo "::set-env name=AWS_ACCESS_KEY_ID::${{ secrets[env.AWS_ACCESS_KEY_ID] }}"
    - run: echo $AWS_ACCESS_KEY_ID

Au cas où cela peut aider, après avoir lu les réponses ci-dessus qui ont vraiment aidé, la stratégie que j'ai décidé d'utiliser consiste à stocker mes secrets comme suit:

• DB_USER_MASTER
• DB_PASSWORD_MASTER
• DB_USER_TEST
• DB_PASSWORD_TEST

Où MASTER est la branche principale de l'environnement de production et TEST est la branche de test de l'environnement de test.

Ensuite, en utilisant les solutions suggérées dans ce thread, la clé est de générer dynamiquement les clés de la variable secrets . Ces clés sont générées via une étape intermédiaire (appelée vars dans l'exemple ci-dessous) à l'aide des outputs :

name: Pulumi up
on:
  push:
    branches:
      - master
      - test
jobs:
  up:
    name: Update
    runs-on: ubuntu-latest
    steps:
      - name: Create variables
        id: vars 
        run: |
          branch=${GITHUB_REF##*/} 
          echo "::set-output name=DB_USER::DB_USER_${branch^^}"
          echo "::set-output name=DB_PASSWORD::DB_PASSWORD_${branch^^}"
      - uses: actions/checkout@v2
        with:
          fetch-depth: 1
      - uses: docker://pulumi/actions
        with:
          args: up -s ${GITHUB_REF##*/} -y
        env:
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          GOOGLE_CREDENTIALS: ${{ secrets.GOOGLE_CREDENTIALS }}
          PULUMI_ACCESS_TOKEN: ${{ secrets.PULUMI_ACCESS_TOKEN }}  
          DB_USER: ${{ secrets[steps.vars.outputs.DB_USER] }}  
          DB_PASSWORD: ${{ secrets[steps.vars.outputs.DB_PASSWORD] }}  

Remarquez le hack pour obtenir la branche en majuscules: ${branch^^} . Cela est nécessaire car GitHub force les secrets en majuscules.

Je suis tombé sur cette question en essayant d'implémenter la sélection secrète basée sur l'environnement pour une action Github.

Cette variable-mapper l' action ( https://github.com/marketplace/actions/variable-mapper ) met en œuvre le concept souhaité de mapper une variable clé ou un nom d'environnement secrets ou d' autres valeurs prédéfinies.

L'exemple d'utilisation montre ceci:

on: [push]
name: Export variables corresponding to regular expression-matched keys
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: kanga333/variable-mapper@v1 
      with:
        key: ${{GITHUB_REF#refs/heads/}}
        map: |
          {
            "master": {
              "environment": "production",
              "AWS_ACCESS_KEY_ID": ${{ secrets.PROD_AWS_ACCESS_KEY_ID }},
              "AWS_SECRET_ACCESS_KEY": ${{ secrets.PROD_AWS_ACCESS_KEY_ID }}
            },
            "staging": {
              "environment": "staging",
              "AWS_ACCESS_KEY_ID": ${{ secrets.STG_AWS_ACCESS_KEY_ID }},
              "AWS_SECRET_ACCESS_KEY": ${{ secrets.STG_AWS_ACCESS_KEY_ID }}
            },
            ".*": {
              "environment": "development",
              "AWS_ACCESS_KEY_ID": ${{ secrets.DEV_AWS_ACCESS_KEY_ID }},
              "AWS_SECRET_ACCESS_KEY": ${{ secrets.DEV_AWS_ACCESS_KEY_ID }}
            }
          }
    - name: Echo environment
      run: echo ${{ env.environment }}

Il existe une option beaucoup plus propre pour y parvenir en utilisant la fonction de formatage .

Étant donné les secrets définis DEV_A et TEST_A, les deux travaux suivants utiliseront ces deux secrets:

name: Secrets

on:
  workflow_dispatch:
    inputs:
      env:
        description: "Environment to deploy to"
        required: true

jobs:
  secrets:
    name: secrets
    runs-on: ubuntu-18.04
    steps:
      - run: echo ${{ secrets[format('{0}_A', github.event.inputs.env)] }}

Cela fonctionne également avec les entrées fournies via les workflows manuels (l'événement workflow_dispatch ):

name: Secrets

on: [push]

jobs:

  dev:
    name: dev
    runs-on: ubuntu-18.04
    env:
      ENVIRONMENT: DEV
    steps:
      - run: echo ${{ secrets[format('{0}_A', env.ENVIRONMENT)] }}

  test:
    name: test
    runs-on: ubuntu-18.04
    env:
      ENVIRONMENT: TEST
    steps:
      - run: echo ${{ secrets[format('{0}_A', env.ENVIRONMENT)] }}

Actions GitHub: abandon des commandes set-env et add-path

Voici la nouvelle méthode à compter du 1er octobre 2020

jobs:
  example-job:
    name: example
    runs-on: ubuntu-latest
    steps:
    - name: log untrusted output
      run: |

        # disable command workflow processing
        echo "::stop-commands::`echo -n ${{ github.token }} | sha256sum | head -c 64`"

        # log untrusted output
        echo "untrusted output"

        # enable workflow command processing
        echo "::`echo -n ${{ github.token }} | sha256sum | head -c 64`::"