Skip to main content

​
Environment variables

env_vars sets variables for every job on the runner — build flags, cache directories, registry hosts.
These are not secret. They are visible in the launch metadata and to every job on the runner. Secrets belong in GitHub Actions secrets, which never pass through Airship at all.
A name starting with GITHUB_, RUNNER_ or ACTIONS_ is refused on purpose: a config file must not be able to change how the runner talks to GitHub.

​
Cloud identity

By default a runner has no cloud identity. Nothing in a job can mint a credential from the metadata service, which is what you want for the great majority of jobs.
The connected IAM user needs iam:PassRole for that role, scoped to it — the statement is here.
An attached identity is available to every step of every job on that runner — including, on a public repository activated for public access, a fork pull request’s code. Treat it exactly as you would a repository secret: scope it narrowly, and keep it off runners that serve untrusted code.

​
Provisioning from your image

By default the boot script travels in the machine’s launch metadata. If you would rather it did not, provision_via: pull_from_api launches the machine with no user data at all, and your image fetches the script itself:
Your image then runs something like this at boot, with a developer API token baked in:
The runner’s name is on the instance’s Name tag. The script is handed out once per runner, so a second request gets nothing. Neither is strictly safer; they move the exposure. Security states both plainly. Most people should leave the default alone.

​
What the machine does at boot

Knowing the order helps when you are debugging an image:
1

Schedule its own shutdown

Before anything else, so a machine whose script later fails still goes away.
2

Write a one-boot marker

A rebooted machine powers off rather than registering twice.
3

Find or install actions/runner

/opt/actions-runner with a matching .version file is used as-is. Otherwise it is downloaded and its dependencies installed.
4

Apply env_vars, and the GPU driver if needed

Into the runner’s own environment file, so every step sees them.
5

Start the cache proxy, if cache is on

And trust its local certificate authority. Caching
6

Register and run one job

Then power off, whatever the outcome.
On Linux the boot log is at /var/log/cloud-init-output.log, and the cache proxy’s own log at /var/log/airship-cacheproxy.log.