Comment by cyberax

8 days ago

You might want (or _need_) to sign your binary, for example. Or you might want to trigger a deployment.

Github actually is doing something right here. You can set it up as a trusted identity provider in AWS, and then use Github to assume a role in your AWS account. And from there, you can get access to credentials stored in Secret Manager or SSM.

6 comments

cyberax

jdeastwood 8 days ago

Yes, their oidc setup was probably their last good feature back when they were actually delivering features back in 2020ish. Everyone else copied it within a few months though.

sofixa 7 days ago
Who is everyone? As with pretty much every GitHub feature, GitLab had them beat by a few years.
- jdeastwood 7 days ago
  
  Maybe in some other form, but the current style of injecting an oidc token was definitely in github actions first. Here is the gitlab issue tracking the final bit of it's implementation directly mentioning github: https://gitlab.com/gitlab-org/gitlab/-/issues/356986
  
  1 reply →

DuncanCoffee 8 days ago

Yeah I sign my project APKs so people can install them from the action's artefact

  - name: Retrieve keystore for apk signing
    env:
      KEYSTORE: ${{ secrets.KEYSTORE }}
      run: echo "$KEYSTORE" | base64 --decode > /home/runner/work/keystore.pfk

amluto 6 days ago

Exactly. This workflow step takes a rather important secret and sticks it on a VM where any insufficiently sandboxed step before or after it can exfiltrate it.
GitHub should instead let you store that key as a different type of secret such that a specific workflow step can sign with it. Then a compromised runner VM could possibly sign something that shouldn’t be signed but could not exfiltrate it.
Even better would be to be able to have a policy that the only thing that can be signed is something with a version that matches the immutable release that’s being built.