Improve security around ACTIONS_RUNTIME_TOKEN (Part 1)

[aomarks]

Background

Wireit's GitHub Actions caching integration works by talking to the GitHub caching HTTP service, which is secured through a secret token. GitHub Actions automatically provides this token to re-usable actions like this one (google/wireit@setup-github-actions-caching) through the ACTIONS_RUNTIME_TOKEN environment variable. However, it does not expose this environment variable to the calling workflow, which is where Wireit is actually running, and is where we actually need it.

Previously, our solution was to read the ACTIONS_RUNTIME_TOKEN environment variable from the called-workflow, and simply expose it directly to the calling-workflow by writing it to the GITHUB_ENV file (see https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/variables).

This is not ideal because that token is sensitive, and we would like to minimize the chance of it leaking out. One way it can leak is if a process logs all of its environment variables.

(Note that the GitHub Actions runner is smart enough to know that this token is sensitive, so it masks out the value with ***s when it appears in the runner's own logs. However, this doesn't help if the environment variables are logged in some other way.)

Changes

Now, instead of exposing the ACTIONS_RUNTIME_TOKEN variable directly, we instead start up a "custodian" HTTP server, which lives for the duration of the workflow, and whose only role is to respond to any HTTP request with the token. We then expose the WIREIT_CACHE_GITHUB_CUSTODIAN_PORT environment variable to the calling-workflow (this provides a positive signal that the custodian is running, and lets us be dynamic with port assignment). Wireit processes can then make a fetch to the custodian service to read the token.

Alternatives considered

An alternative considered was to write the token to a known location on disk, like $RUNNER_TEMP/.wireit-caching-github-token. This would solve for the case where environment variables are being logged, but introduces another way the token could leak out (one can imagine a GitHub Action that uploads the temp directory somewhere for some kind of debugging reason). The HTTP approach should be much less liable to leak than either of the other approaches.

Plan

• Land this PR (note that the GitHub Action lives on its own setup-github-actions-caching branch, which is the base for this PR).
• Land Improve security around ACTIONS_RUNTIME_TOKEN (Part 2) #1147 which updates Wireit to support both the old and new approaches, and warns if the old method is detected.
• Release -pre versions of each to test caching still works for real.
• Release v2 of the action (which is done simply by Git tagging).
• Release a patch version of Wireit.
• Sometime in the future: remove support for the old approach.