Upgrade all third-party actions and pin them to immutable releases#14
Conversation
Agent-Logs-Url: https://github.com/ccao-data/api-res-avm/sessions/3418a7a0-8638-4529-8159-917f963ff576 Co-authored-by: jeancochrane <14170650+jeancochrane@users.noreply.github.com>
Agent-Logs-Url: https://github.com/ccao-data/api-res-avm/sessions/490a12f5-1234-441e-bf5b-3acc235de2ac Co-authored-by: jeancochrane <14170650+jeancochrane@users.noreply.github.com>
| steps: | ||
| - name: Checkout | ||
| uses: actions/checkout@v3 | ||
| uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2 |
There was a problem hiding this comment.
actions/checkout does not use immutable releases, so we need to pin to the commit hash for the most recent release.
There was a problem hiding this comment.
more just out of curiosity- does this mean if/when there are (stable) updates we'll have to go back and change this manually?
There was a problem hiding this comment.
Yup, that's right. It's a trade-off inherent to hardening our Actions supply chain. I'm now watching releases for the third-party actions that we use in our workflows across all repos, which should help mitigate the risk of us missing security releases for third-party actions that we use.
|
|
||
| - name: Setup Docker Buildx | ||
| uses: docker/setup-buildx-action@v2 | ||
| uses: docker/setup-buildx-action@v4.1.0 |
There was a problem hiding this comment.
docker/setup-buildx-action does use immutable releases, so we can pin to a specific version and have confidence that a malicious actor cannot change it. We can confirm that the release is immutable by looking for the 🔒 Immutable icon on the release page:
| runs-on: ubuntu-latest | ||
| permissions: | ||
| contents: read | ||
| packages: write # Allow workflow to push images to GHCR |
There was a problem hiding this comment.
This permission is now necessary in order to allow docker/build-push-action to push images to the GitHub Container Registry (GHCR) for our repo. I discovered this fact and tested it in ccao-data/service-spark-iasworld#39. See the docs on Authenticating to package registries with repository-scoped permissions for instructions indicating that this is the correct choice:
You should set the permissions for this access token in the workflow file to grant read access for the
contentsscope and write access for thepackagesscope.
I tested the change by temporarily configuring PR builds to push to GHCR in baea997, then confirming that the push step succeeds.
TimCookCountyDS
left a comment
TimCookCountyDS
left a comment
There was a problem hiding this comment.
Thanks! this all makes sense to me-
Thanks for adding the testing note.
| steps: | ||
| - name: Checkout | ||
| uses: actions/checkout@v3 | ||
| uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2 |
There was a problem hiding this comment.
more just out of curiosity- does this mean if/when there are (stable) updates we'll have to go back and change this manually?
This PR upgrades all of our third-party GitHub Actions to ensure they are compatible with the upcoming Node 20 deprecation.
While we're at it, we also switch all of our references to third-party actions to point to immutable releases, so as to protect ourselves from the the ongoing scourge of supply chain attacks against third-party actions. If an action repo is using immutable releases, we pin to a specific immutable release; otherwise, we pin to the commit hash for the latest release of that action.
Test workflows to confirm these upgrades don't break anything:
pre-commit: https://github.com/ccao-data/api-res-avm/actions/runs/26314708657/job/78539538994docker-build: https://github.com/ccao-data/api-res-avm/actions/runs/27222622981/job/80381180263Connects https://github.com/ccao-data/aws-infrastructure/issues/59.