Hacker News Reader

Comment by arkadiyt | Hacker News Reader

Great reminder for folks to switch any AWS actions you perform from CI/CD to use OIDC role assumption instead of static IAM user credentials. Then even if an attacker stole all your secrets they can't do anything in your AWS account.

View on HN

I recently did this for one of my GitHub repos which runs several test suites (cumulatively taking >1h). If your actions are slow, pay attention to the IAM role session duration. The maximum duration with role chaining is 1 hour.

In the end your credentials need to outlive your CI/CD actions.

Throwaway for reasons:

From experience, be careful and ensure you properly scope your OIDC connection. It’s very easy to allow ANY GitHub repo with proper OIDC connection bits (SA email, connector pool, etc) to get an OIDC token, rather than what you expect, whether that’s any repo in your private org or a specific single repository. As always, RTFM

I believe the max duration of an assumed role session is 12 hours, but this can be changed per-role.

For assuming one role it can be up to 12 hours. If you're doing role chaining like the parent mentioned (where the 1st assumed role then assumes a 2nd role) then the maximum session duration is 1 hour. AWS has this documented here:

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_te...

> Role chaining limits your AWS CLI or AWS API role session to a maximum of one hour.

Can you elaborate, as someone with little AWS experience? Are OIDC based creds just more scoped? What makes them special?

To assume a role with OIDC you'd need to do it from the context of a specific CircleCI job run - getting access to the secrets of a particular CircleCI account alone would not be enough to authenticate to AWS (unlike when you use IAM user credentials).

Even if the attacker had access to env vars from running jobs (which includes the signed token needed to do an OIDC role assumption), those tokens have a short expiry time, and even if an attacker stole that token and performed a role assumption then that session can only be valid for a maximum of 12 hours in AWS, and then you know the attacker is out of your account.

It just significantly reduces, practically nullifies, anything that an attacker can do in your AWS account.

This only applies if the stolen credentials can’t create roles and can’t modify existing roles.

...and don't leave a payload behind, to maintain persistent access (unless I'm missing something?)

This is a good reminder to always follow least-permission best practices.

I’d add drift detection on everything IAM / SCP / Org to this list too.

A session token with only a few minutes validity can be enough for someone to make their access permanent.

I assume what they meant is having AWS accept short-lived OIDC tokens from Circle's OIDC provider, which in turn would generate them on demand when the CI is actually run. There'd be no secrets at rest and the attack surface would be (in principle) smaller.

While OIDC is a good option, at StepSecurity, we are building an open-source project that allows using your MFA tokens for deployments in CI/ CD. So far, it is implemented for GitHub Actions - https://github.com/step-security/wait-for-secrets. In this method, you get a link in the build log, click the link, and can enter credentials at run time, which then gets used in the next step in the pipeline for deployment. So there are no persistent secrets stored in the CI/ CD pipeline and no need for managing/ rotating separate deployment credentials.

A bit of a shameless plug for a relevant Terraform module I made (specific to GitHub in this case): https://github.com/unfunco/terraform-aws-oidc-github

Reply on news.ycombinator.com