How to use reusable GitHub workflows and keep secrets in a single place?

user_99834 0
Viewed 2453

While reusable GitHub workflows do help with maintenance of GitHub Actions in general, reducing a lot of copy/paste from one repository to another, they still seem to have one big issue: dealing with secrets.

When implementing an action like "post to Slack", or "post to matrix/IRC", you will need some secrets for the bot account, and if you want to reuse this action in 50 repositories you can imagine while managing secrets in each repository does not scale.

I am looking for a solution to this problem that does not involve deploying secrets to all repositories using an action, some way to centralize them.

Keep in mind that reusable workflows work across organizations and I already have some of them shared across 4+ organizations. So configuring organization level secrets is not a solution either, also for other reasons: they can easily be exposed because they are available to any workflow (as opposed to environment based ones).

github-actions
2 Answers

Check if the new (May 2022) keyword secrets: inherit can help:

GitHub Actions: Simplify using secrets with reusable workflows

GitHub Actions simplifies using secrets with reusable workflows with the secrets: inherit keyword.

Previously when passing secrets to a reusable workflow, you had to pass each secret as a separate argument.

Now you can simply pass the secrets: inherit to the reusable workflow and the secrets will be inherited from the calling workflow.

Learn more about reusable workflows in GitHub Actions.

In the reusable workflow, reference the input or secret that you defined in the on key in the previous step.

If the secrets are inherited using secrets: inherit, you can reference them even if they are not defined in the on key.

jobs:
 reusable_workflow_job:
   runs-on: ubuntu-latest
   environment: production
   steps:
     - uses: ./.github/workflows/my-action
       with:
         username: ${{ inputs.username }}
         token: ${{ secrets.envPAT }}

In the example above, envPAT is an environment secret that's been added to the production environment. This environment is therefore referenced within the job.

Note: Environment secrets are encrypted strings that are stored in an environment that you've defined for a repository.
Environment secrets are only available to workflow jobs that reference the appropriate environment.
For more information, see "Using environments for deployment."

VonC_63090

Organization secrets can help with this problem, but it's not an ideal solution for all use cases. Your situation is similar to a situation I had with implementing SAST. Rather than having each team setup the job manually and incorrectly set failure levels or forget to output to SARIF and upload, I just created a reusable job. The challenge is the API credentials weren't available from the called workflow repository secrets. I can work around this with org secrets. I have other use cases, where it's much more difficult to use an org secret and still enforce good behavior.

user_193953030
Related