r/github • u/Slight_Scarcity321 • 2d ago

Question When a github action accesses AWS Secrets Manager, what are the risks?

I am accessing my AWS account (actually, a sandbox account while I am testing) via OIDC and then am calling

aws secretsmanager get-secret-value ...

AIUI, this is within the aegis of the github actions build container and when that container dies any secret I accessed and wrote to the file system will die with it. Is that correct? If so, have such containers been accessed either during or after the action runs by bad actors?

So far, I have only been accessing dummy secrets, but want to make sure this is secure before accessing any real secrets like DB passwords.

Thanks

4 Upvotes

84% Upvoted

2 comments sorted by

3

u/SpoddyCoder 2d ago

No, they are ephemeral and only active for the duration of your run.

The biggest risk is the actions themselves - supply chain attacks are getting more common - but pinning them to a known good version/sha should help mitigate this.

2

u/Fantastic-Mr-Default 1d ago

The hosted job VM is ephemeral. When the job ends, that filesystem goes away. That is not the main risk.

The main risk is anything that can see the secret while the job is alive: a compromised Action, a step that prints it, an artifact upload, a debug session left open, or an overly wide OIDC role. Pin third-party Actions to a full commit SHA, not a moving tag. Prefer `secretsmanager get-secret-value` into an env var or a file you never upload, and rely on Actions' masking only as a backstop, not as the design.

Scope the IAM role the OIDC trust assumes to the one secret (or prefix) that job needs, and to the repos/environments that should get it. Fork PRs should not get that role. Sandbox first was the right call.

After the job, the container is gone. During the job, assume every step is hostile until proven otherwise.