Comment by mdaniel | Hacker News Reader

Comment by mdaniel | Hacker News Reader

Parent Full thread

> Search for and leak `AWS_ACCESS_KEY_ID` anyone?

Well that's just someone being a dumbass, since AssumeRoleWithWebIdentity (and its Azure and GCP equivalent) have existed for quite a while. It works flawlessly and if someone does do something stupid like `export HURP_DURP=$AWS_ACCESS_KEY_ID; printenv` in a log, that key is only live for about 15 minutes so the attacker better hurry

Further, at least in AWS and GCP (I haven't tried such a thing in Azure) on can also guard the cred with "if the organization and repo are not ..." then the AssumeRole 403s to ensure that my-awesome-org/junior-dev-test-repo doesn't up and start doing fun prod stuff in GHA

I hate GHA probably more than most, but one can footgun themselves in any setup

I never knew how easy it was to setup role assuming for AWS/GHA. It’s much easier than managing the access/secret.

I wrote a little about it in this blog post: https://joshstrange.com/2024/04/26/nightly-postgres-backups-...

If you, or others, are interested I have found that those role-session-name variables make for a great traceability signal when trying to figure out what GHA run is responsible for AWS actions. So instead of

  role-session-name: GitHubActionSession

one can consider

  role-session-name: gha-${{ github.run_id }}  # or your favorite

I don't this second recall what the upper limit is on that session name so you may be able to fit quite a bit of stuff in there

Great points. I totally agree, don't use hard-coded static creds, especially here. But in reality, many services and/or API keys don't support OIDC or short-lived credentials, and the design of secrets in GitHub promote using them, in my opinion.

Reply on news.ycombinator.com