4 ms·

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 at

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.

ollien 4y ago
Can you elaborate, as someone with little AWS experience? Are OIDC based creds just more scoped? What makes them special?
- woodruffw 4y ago
  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.
- arkadiyt 4y ago
  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.
  - rcme 4y ago
    This only applies if the stolen credentials can’t create roles and can’t modify existing roles.
    - thinkmassive 4y ago
      ...and don't leave a payload behind, to maintain persistent access (unless I'm missing something?)
    - Corrado 4y ago
      This is a good reminder to always follow least-permission best practices.
      - danw1979 4y ago
        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.
shitlord 4y ago
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.
- ary 4y ago
  I believe the max duration of an assumed role session is 12 hours, but this can be changed per-role.
  - arkadiyt 4y ago
    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_terms-and-concepts.html 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.
- deleted 4y ago
  [deleted]
- bazookaworkable 4y ago
  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
unfunco 4y ago
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 https://github.com/unfunco/terraform-aws-oidc-github
varunsharma07 4y ago
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 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.

ollien 4y ago

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

woodruffw 4y ago
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.
arkadiyt 4y ago
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.
- rcme 4y ago
  This only applies if the stolen credentials can’t create roles and can’t modify existing roles.
  - thinkmassive 4y ago
    ...and don't leave a payload behind, to maintain persistent access (unless I'm missing something?)
  - Corrado 4y ago
    This is a good reminder to always follow least-permission best practices.
    - danw1979 4y ago
      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.

shitlord 4y ago

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.

ary 4y ago
I believe the max duration of an assumed role session is 12 hours, but this can be changed per-role.
- arkadiyt 4y ago
  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_terms-and-concepts.html 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.
deleted 4y ago
[deleted]
bazookaworkable 4y ago
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

unfunco 4y ago

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 https://github.com/unfunco/terraform-aws-oidc-github

varunsharma07 4y ago

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 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.