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.

▲ jdeastwood a day ago | parent | next [-]

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 a day ago | parent [-]

Who is everyone? As with pretty much every GitHub feature, GitLab had them beat by a few years.

▲

jdeastwood 15 hours ago | parent [-]

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

	▲	sofixa 15 hours ago \| parent [-]
		This is the more flexible and secure (specific aud) replacement for CI_JOB_JWT which has been there since at least 2017, if not before. Functionally it was exactly the same, a JWT token per pipeline allowing you to authenticate to third parties that support OIDC/JWT Auth.

▲ DuncanCoffee a day ago | parent | prev [-]

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 an hour ago \| parent [-]
		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.