4.1 KiB
| title | license |
|---|---|
| Forgejo Actions | Security | CC-BY-SA-4.0 |
Forgejo Actions is a very flexible CI/CD system. It lets you write workflows that execute arbitrary code, with contents of potentiall private repositories. This brings some security risks. This page details the security design of the Actions system, and any considerations you should be aware of.
Security Design
Forgejo Actions consists of two main parts: The Forgejo server, which contains the repository and hands out workflow runs; and the Forgejo runner, which receives workflow runs and executes them. One server may have many different runner attached, which are registered to different users or organizations.
Automatic token
When a workflow is started, a unique authentication token is automatically created. It can be used to read the repositories associated with the workflow, even when they are private. This token is automatically destroyed when the workflow finishes.
This token can only be used for interactions with the repository it was created for, and any attempt to use it on other repositories will return a 404 error.
Pull requests
Workflows triggered by the pull_request event are an exception. The token generated for these runs does not have write permissions for the repository, since a pull request is not verified and could contain an untested or malicious workflow.
The first time a user proposes a pull request, the on.pull_request workflows are blocked.
They can be approved by a maintainer of the project and there will be no need to unblock future pull requests.
If a trusted user attempts to abuse the actions system, they can be blocked. This will revoke the user's ability to run pull_request workflows.
The on.pull_request_target workflows are not subject to the same restriction and will always run.
Runner
The Forgejo Runner attempts to isolate different workflow runs from each other as much as possible. How this is achieved depends on the kind of runner it is.
Docker, Podman and LXC runners
In the case of a runner which uses OCI (Docker, Podman) or LXC containers, a new container will be created for each workflows. The containers provide isolation from the host system and other containers.
However, if the container environment is misconfigured it may be possible for a workflow to escape its confinement and perform potentially malicious actions. This may compromise the runner, which means that any future workflows sent to this runner may also be compromised.
Host runners
Host runners have no real isolation. When a workflow finishes the appropriate folders are cleaned up, so any workflows that stay within the intended bounds shouldn't have any effect on each other.
It is trivially easy to 'escape' on a host runner, and all sorts of malicious things can be done.
Secrets
Secrets can be used to store passwords or tokens for use in a workflow. They are stored encrypted in the Forgejo database, and sent out to workflows when they are needed. More information.
Forgejo Runner attempts to automatically redact secrets from the logs.
Security considerations
When using Actions, keep in mind the following considerations:
Runner
- Container runners are generally safe, but they may be compromised if misconfigured.
- Never trust a host runner if it is shared with other users.
- The safest option is to host your own runner, and use it only for your trusted repositories.
Pull requests
- Carefully review changes to the workflows, and only approve workflows from trusted users.
- Prefer
on.pull_request_targetoveron.pull_requestwhenever possible. - Block users that aren't trusted to prevent them from running malicious workflows through PRs.
Secrets
- Use the secrets feature to store API tokens and passwords for use in workflows.
- Do not print secrets to output, as these may be publicly visible.