Sending secrets with repository_dispatch triggers to avoid GITHUB_TOKEN limitations -- good idea or security risk?

[grahamalama]

Select Topic Area

Question

Body

I've been thinking about ways to avoid the fact that you can't trigger other workflows from workflows that use GITHUB_TOKEN (docs).

Some context -- the specific problem I'm looking to solve is automating pull requests to update values that represent version numbers for things that Dependabot doesn't know how to update. This could be used for any PR automation workflow, though.

I don't want to rely on PATs or upload an app's private key in each repository where I want to run a similar workflow. I had an idea for a way to avoid doing both of those things, but I'm wondering if it would be a bad idea from a security perspective:

• Create an app, and install it in each repository where we want to run these custom update workflows

• In some central repo, run a workflow on a cron schedule that sends repository_dispatch events to configured repos to trigger these custom update workflows. Part of the client_payload would include the same installation token that'd be used to authorize the repository_dispatch call:

  payload=$(jq -n --arg installation_token $installation_token '{"event_type":"check_for_update","client_payload":{"dependency":"blah", "token": $installation_token}}')
  curl -L \
    -X POST \
    -H "Accept: application/vnd.github+json" \
    -H "Authorization: Bearer $installation_token" \
    -H "X-GitHub-Api-Version: 2022-11-28" \
    https://api.github.com/repos/$owner/$repo/dispatches \
    -d "$payload"

• In each repo that wants to run some custom update workflow, create that workflow and specify repository_dispatch as a trigger. For workflow steps that require a token, provide it as an env value:

      # Now, regular PR actions like linting and tests will be triggered
      - name: Create pull request
        env:
          GITHUB_TOKEN: ${{ github.event.client_payload.token }}
        run: |
          ...

Providing this token has the minimal permissions necessary to complete this workflow and was scoped only to the repo where the workflow was running, there'd still be risk of the token leaking, but it seems that the damage would be minimal?

I'm wondering if I'm overlooking any risk, or if there's a better better way to go about achieving my goals entirely.