Running workflows on dispatch should have their own permission

[franpb90]

Select Topic Area

Product Feedback

Body

From my understanding to trigger a workflow_dispatch you need to have write permissions on the repository.

We are facing the following situation. We have an internal repository in an organization where all organization members have read access. We want to give them access just to trigger the workflow on a specific branch. We do not want that they can modify the workflows and be able to expose the secrets, take advantage of the privileges configured in the repo, or skip any workflow validation.

In my opinion, running workflows permission should have it's own permission, instead of using the repository write permission. I think it will help to have this permission separated from write permissions, similar like in file permissions we have read, write, and execute

Related discussion:
Who has permission to workflow_dispatch

[ecs-jnguyen]

Additionally, branch protection is not good enough. If you grant me write access to a repo, I can create my own branch modify the workflow file then run the workflow using my branch.

[NullVoxPopuli]

I'm running in to this issue as well.
I'm trying to sanely (as in, not what's in GitHub's blog) dispatch a trusted workflow from an untrusted one -- example: PR fork submits a PR -- I want to still give that PR a deploy preview -- and the deploy-preview workflow has secrets -- but those secrets are not available to forks.

[gusmith-ambiata]

@franpb90 and @ecs-jnguyen
In the branch protection, there is the following option:

I'm trying to turn my head around if this would solve the issue:

1. create a team REPO_WRITERS for users who will be able to write in the repo giving this team a write role
2. create a team GITHUB_ACTION_MANUAL_RUNNERS for users who will have write permissions on the repo BUT should not be allowed to write anywhere (cf following), give this team write role
3. create a branch protection rule where the branch selection is * (i.e. all branches) where only the REPO_WRITERS team is allowed
   

Should that work? I have not tested it yet.

I was otherwise looking at the CODEOWNERS file but it seems you can still update the file in your feature branch, you just cannot merge it without a code owner review, and thus do not solve the original problem.

However, I cannot think of a way to provide write access to the whole repo BUT the github workflow folder, blocking pushes even if on feature branches...

[gusmith-ambiata]

It is actually not working for a weird reason: with this branch protection, you can still create branch with a commit. The branch WILL be protected after that, but not on the first push. Odd no?

[gusmith-ambiata]

A colleague mentioned a great idea: triggering a workflow through issues.
People with READ role can create issue. You then parse the content/title of the issue triggering the workflow.

Probably not the perfect solution, but it should solve the issue of triggering a workflow for READ only users that @franpb90 mentioned.

[franpb90]

It is a good idea. We have started to use this workaround, but we have not tested it at scale yet.

[dcopso]

I've been using this approach for over a year and it works fine.

Here's the skeleton of the action on the repository with privileges:

# example workflow to be triggered by the opening of an issue, running a privileged task, and notifying slack of
# the results.
on:
  issues:
    types:
      - opened

permissions:
  issues: write  # Allow the workflow to update the opened tickets.

env:
  LOG_URL: ${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}

jobs:
  sync:
    if: |
      !github.event.issue.pull_request
        && startsWith(github.event.issue.title, 'INVOKE-MAGIC-STRING')
        && (github.actor == 'github-machine-user-for-your-automations')
    runs-on: ubuntu-22.04
    timeout-minutes: 10
    steps:
      - run: |
          gh api "${ISSUE_REACTIONS_URL}" -f content=rocket
        env:
          GH_REPO: ${{ github.event.repository.full_name }}  # Tell gh CLI which repo to use.
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}  # Provide auth token to gh CLI for this repository.
          ISSUE_REACTIONS_URL: ${{ github.event.issue.reactions.url }}
      - run: |
          # run the task you want to trigger here.
          curl -H "Authorization: Bearer $WHATEVER_SECRET" ...
        env:
          WHATEVER_SECRET: ${{ secrets.WHATEVER }}
      - if: success()
        uses: your-preferred/slackbot-notifier@main
        with:
          webhook_url: ${{ vars.SLACK_WEBHOOK_URL }}
          message: "Privileged task has completed. Log: ${{ env.LOG_URL }}"
      - if: failure()
        run: |
          gh issue comment "${ISSUE_NUMBER}" -b "Failure: ${LOG_URL}"
        env:
          GH_REPO: ${{ github.event.repository.full_name }}  # Tell gh CLI which repo to use.
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}  # Provide auth token to gh CLI for this repository.
          ISSUE_NUMBER: ${{ github.event.issue.number }}
      - if: failure()
        uses: your-preferred/slackbot-notifier@main
        with:
          webhook_url: ${{ vars.SLACK_WEBHOOK_URL }}
          message: "Privileged task has failed. Log: ${{ env.LOG_URL }}"

To invoke it, the other repository can open an issue in the privileged repository:

# creates an issue in the TARGET_REPO repository
on:
  workflow_dispatch:

env:
  # consumed by gh cli. The GitHub username of the user that creates this token should be dropped into
  # the above YAML file to replace 'github-machine-user-for-your-automations'.
  GH_TOKEN: ${{ secrets.TOKEN_WITH_READ_ACCESS_ON_PRIVILEGED_REPOSITORY }}
  TARGET_REPO: "my-organization/your-privileged-repo"

jobs:
  call:
    timeout-minutes: 10
    runs-on: ubuntu-22.04
    steps:
      - run: |
          gh issue create \
            -t "INVOKE-MAGIC-STRING" \
            -R "${TARGET_REPO}" \
            --body "Created by: https://github.com/${GITHUB_REPOSITORY}/actions/runs/${GITHUB_RUN_ID}"

[chaochn47]

It is wanted as mentioned in etcd-io/etcd#15659. @franpb90 and @gusmith-ambiata could you please share how it is set up?

[DavidWHarvey]

A somewhat convoluted solution I'm going to try the last piece of.

The actual environment we want to deploy to is in Azure, and we are using OIDC in the workflow. Each Azure environment has a separate federated managed identity to the github environment. We needed an action run in a separate job to find the environment for a branch, and to use the output of that job to set the environment for a workflow in a second job. This action enumerates the environments to create a mapping of branch name patterns to github env. If the current branch matches exactly one environment, then that is the environment selected. That second job then uses OIDC to login to Azure, where the identity federation authenticates the github environment's identity. This action runs a simple python script that calls GH API to collect this info,

It seems like we will be able, in that action, to fail if the workflow was triggered by an actor that is not one of the CODEOWNERS.

The basic issue there are users with write access to the repo that effectively do not have write access to specific branches based on branch protection rules, but the github workflows has no mechanism to determine whether the triggerer has write access to the branch.

[shayki5]

+1

[jtv8]

This is required for both of these events, IMO:

Endpoint	Current permission required
/repos/{owner}/{repo}/actions/workflows/{workflow_id}/dispatches	"Actions" repository permissions (write)
/repos/{owner}/{repo}/dispatches	"Contents" repository permissions (write)

The latter one is particularly silly. The endpoint is designed to:

trigger a webhook event called repository_dispatch when you want activity that happens outside of GitHub to trigger a GitHub Actions workflow or GitHub App webhook.

Processes that happen outside of GitHub should not be given any more than the permissions they explicitly need, and certainly not permission to write repository contents.

These two dispatch events could be very useful for providing a limited external interface for your CI/CD automation infrastructure. But the current design does not follow the principle of least privilege, which means that developers are forced into hacky solutions like using issues or using branch protection rules to try to close the holes that these permissions open.

Fixing this issue would also enable developers to use https://github.com/peter-evans/repository-dispatch (or similar actions) to dispatch an event in another repository using a limited token that properly follows the least-privilege principle.

+1 for the idea of an execute permission on certain resources. That's an elegant way of solving this. If that's not possible, then write permission on a more tightly defined resource like "Dispatches" would also work.

[sandstrom]

@hpsin Happy New Year! 😄

Just wanted to ping you to hear if there are any plans to update what permissions are required for repository_dispatch (and I guess also workflow_dispatch)?

Right now they both require read and write to repository contents, which makes them tricky to use for integrations with external systems. Basically, we're reluctant to give external sources write-access to the repo (I know there are branch protection rules etc, but still).

It would have been awesome if there was a more narrow permission that we could use, that would only allow triggering the repository_dispatch event.

I know you probably have a lot of wishes coming in, but wanted to put this one out there. Perhaps it's useful if you are planning your work for the upcoming year.

[PaulRBerg]

+1

This is an important security feature

[nkilders]

My team uses Rulesets to control which people have full write permissions and which people should only be able to run workflows. Therefore, we created a Ruleset which restricts the creation, updates and deletions of branches. Only repository admins are allowed to bypass these restrictions. Thus, people with write permission can run workflows but cannot create new or update existing branches. You could also add other teams or roles to the bypass list to realise a different behaviour.

Screenshots

One advantage compared to the issue approach described above: in case your workflow requires input arguments, you don't have to implement extra logic to extract the data from the issue description. Instead you can use the default dispatch dialog from GitHub. This reduces error potential and complexity.

Like the other approaches described before this isn't an ideal solution and there are probably edge cases which my team hasn't noticed so far (In case you see some, please let me know). However, it works for our use cases.

[MUFFANUJ]

+1

[vladislav-zalesak]

+1

[sassaupdate]

I agree with this. Triggering a workflow_dispatch should not require full write access, because write permission opens the door to much more than simply running a workflow. A separate “run workflow” or “execute workflow” permission would be a much safer and more practical model.

There are many real cases where teams need controlled execution without code-changing privileges. For example, if a team manages a public-facing service such as a SASSA status check platform, certain staff may need to run deployment, sync, or reporting workflows on demand, while still having no ability to edit workflows, expose secrets, or bypass protections. The same applies to admin tools related to SASSA pensions, where operational access and repository write access should clearly remain separate.

So the request makes sense from both a security and operations perspective: read, write, and execute should be treated as distinct permissions, not bundled together.