Improve self-hosted runner permissions and restrictions

[Torxed]

Select Topic Area

Product Feedback

Body

I'd like to propose a small change to drastically improve self-hosted runners and their permissions/workflow.

Short version:

• Allow all existing workflows - changes or new workflows require approval before executing

Here's a walkthrough of the reasoning:

Self-hosted GitHub runner scenario

The premise is to enable:

• Integration tests for archinstall
• Real-world simulations using qemu on a GitHub runner

The goal is to provide easy barrier-to-entry on contributions for both maintainers and contributee's on:

• All PR's
• All branches
• New releases

Ideas / example solutions

• Put access controls on the workflows themselves

  jobs:
    run-qemu:
      name: qemu testbench
      if: ${{ github.actor == 'Torxed' }}
      runs-on: self-hosted
      steps:

• Protect master/main branch from changes and only run workflow on those branches
• Require codereview on any .github/workflows/*.yaml changes before runners execute
• Require approval for all runners (not ideal in terms of maintainability)

All of which are built-in to GitHub.

Downsides

Forcing "Require approvals" makes maintaining test consistency hard in the long run if contribution volume is high.

The following (on purpose) is what causes the most headaches:

on:
  pull_request:

Because if access control to the runner is performed in the GitHub workflow .yaml file, things like this is possible:

• evil change PR

And enforcing code review before runner execution appears to require the use of environment:. If that is the case then it too be removed from a workflow with a PR, thus bypassing those checks.

Locking a runner to master/main makes PR's fall back to manual testing, as it will only be run once the code hits the "live code base".

Proposed solution

Github supports and allows external workflows, which can be restricted in repository settings (meaning, it's outside of user input control):

By creating a workflow there, we can lock master and the repo in its entirety. And we can then call that runner:

Caller:

# ISO build job:
jobs:
  build:
    runs-on: ubuntu-latest
    ...
  runexternal:
    needs: build
    uses: Torxed/archinstall-runner/.github/workflows/qemu-tests.yaml@main
    secrets: inherit

reusable workflow:
With security checks on the first step to legitimate caller:

jobs:
  access-check:
    runs-on: self-hosted
    steps:
      - name: Access check
        run: |
            env
            if [[ "$GITHUB_WORKFLOW_REF" == "archlinux/archinstall/.github/workflows/iso-build.yaml@refs/heads/master" && \
                  "$GITHUB_REPOSITORY" == "archlinux/archinstall" && \
                  "${{ secrets.CALLTOKEN }}" != "" && \
                  "${{ secrets.CALLTOKEN }}" == "$LOCALRUNNER" ]]; then
                exit 0
            else
                exit 1
            fi
  run-qemu:
    name: qemu testbench
    needs: access-check
    runs-on: self-hosted
    steps:

In this "external workflow", we can check immutable values:

• "$GITHUB_WORKFLOW_REF" == "archlinux/archinstall/.github/workflows/iso-build.yaml@refs/heads/master" ensures that the branch calling the external workflow is master
• "$GITHUB_REPOSITORY" == "archlinux/archinstall" ensures the caller comes from a trusted source (mostly here for readability of what's going on)
• "${{ secrets.CALLTOKEN }}" == "$LOCALRUNNER" ensures the secret stored in the calling repo matches that of the local self-hosted runner's environment value.

Running the self-hosted runner with:

• LOCALRUNNER="cowbellsandwhistles" ./run.sh

Allows us to lock a secret/access token on both ends as a final security measure.

Remaining issue

• Prohibit PR's from adding actions that target self-hosted:

  jobs:
    access-check:
      runs-on: self-hosted

  As it will immediately start the job without requiring approval: evil-job.yaml

Conclusion

There's currently no way in GitHub self-hosted runners to prohibit execution of unknown workflows/code, without turning on "Require approval" for all runners.

The best thing would be:

• Require approval for new or modified workflows

In that scenario, we could implement pretty neat runners with security checks in the runners themselves without worrying about evil changes to the runners. As it stands, runners are susceptible to changes that can auto-run (unless require approval is turned on). Unless I missed something basic in my testing.

Or, on the runners run.sh allow specifying which users are allowed to initiate runs, making runners individual with know trust. For instance by evaluating GITHUB_ envs.