Github Actions
Github Actions allow developers to automate tasks like building, testing, and deploying code whenever specific events occur, such as pushing commits, opening pull requests, or publishing releases. Workflows are defined as YAML files stored in the repo, and run inside isolated virtual environments called runners.
Runners
Runners are the execution environments that power GitHub Actions workflows. When a workflow is triggered, a runner picks up the job and runs each step in order on a clean virtual machine or container. GitHub provides hosted runners for common operating systems like Linux, Windows, and macOS, which are automatically created and destroyed for each run. Github has their own runners aswell as the ability for users to use self-hosted runners which allows the users to gain more control, and use custom hardware.
Workflows
Github uses workflows to define and execute Github Actions. these workflow generally sit in the .github/workflows directory and are defined as in a strict YAML format such as the one defined below.
name: Blog
on:
pull_request:
types: [opened, edited, synchronize]
jobs:
validate-pr-title:
name: Blog
runs-on: ubuntu-latest
steps:
- name: Show workflow context
run: |
echo "Repository: ${{ github.repository }}"
echo "Actor: ${{ github.actor }}"
echo "Event: ${{ github.event_name }}"
echo "Token available: ${{ secrets.GITHUB_TOKEN != '' }}"
echo "Ref: ${{ github.ref }}"
The format consisents of the general structure being on:
pull_request:
types: [opened, edited, synchronize] which means this workflow is executed and runs when a pull request is opened, edited or synchronize.
Action Security
Workflows can handle a wide range of tasks, from tagging pull requests to enforce consistent formatting and processes, to more sensitive operations such as building artifacts and deploying release code to various environments. Because of this, workflows often manage sensitive data like credentials and access tokens.
There are generally two main threat scenarios involving workflows:
- An attacker with read access to the repository (for example, anyone viewing a public repository)
- An attacker with write access to the repository (for example, an insider with organizational write permissions)
While there are plenty of resources covering the first scenario, guidance on the latter is limited, even though it poses a significant risk as a potential insider threat.
GitHub Actions workflows are structured into jobs, and each job is made up of one or more steps. Each job runs in its own isolated virtual machine (runner), while steps are individual tasks within that job that execute sequentially in the same environment.
For example, in workflow file above, the job is named validate-pr-title, and one of its steps is show workflow context.
When a step is executed the job
Trigger Table:
| Trigger name | How to trigger | Restrictions |
|---|---|---|
discussion |
Start a new discussion | There is an organization setting to disallow readers from starting new discussions, but readers are allowed by default |
discussion_comment |
Comment on a discussion | |
fork |
Fork a repository | For private repositories, permission to fork repositories must have been granted at the organization level. This is disabled by default. Anyone can fork a public repository. |
issue_comment |
Comment on an issue or a pull request | |
issues |
Create an issue | |
pull_request |
Create a pull request | If the pull request is from a fork, permissions may be needed for actions to run. NB! Readers can create a pull request without forking as long as there are at least two differing branches already present. |
pull_request_review |
Review a pull request | |
pull_request_review_comment |
Make a comment as part of a pull request review | |
pull_request_target |
Create a pull request | Somewhat the same as pull_request but difference in various reasons.. |
watch |
Star a repository |
