AssumeRoleWithWebIdentity seems to have a new, barely-documented, policy
condition key. It's called sts:RoleAuthorizedByIdp and if you're anything like
me (my condolences), that name will pique your interest. It's not super useful
today (unless you're running an OIDC IdP), but its utility will grow as adoption
improves over time. So here's what I've learned so far.
Earlier today, AWS IAM Identity Center launched the ability for server-side applications to assume roles on behalf of their users. This is a big deal, I've wanted this exact kind of functionality for years. The docs are pretty sparse on how it works and what the events look like in CloudTrail, so here are my field notes, recommendations on whether you should use it today and feature requests for whichever AWS service team is working on this.
Lately, I've been interested in how third party vendors can best authenticate into their customers' cloud accounts. The status quo in AWS is usually role assumption from the vendor's account to the customers', but what about GCP and Azure? Can OIDC be used to authenticate into all three clouds in approximately the same way? I think the answer is yes, and this blog post aims to show how to do so.
The short version: AWS IAM Identity Center exchanges third-party OIDC tokens
for Identity Center-issued tokens. Identity Center relies on the jti claim in the
third-party tokens to prevent replay attacks. Identity Center maintained a cache of
previously-seen jti values for a fixed period (24 hours) and didn't enforce that
the third-party tokens had expiry claims. This meant that a token with a jti
claim and without an exp claim could be replayed after >24 hours had passed.
AWS now enforces that these third-party OIDC tokens include an exp claim.
Back in 2021, I requested that AWS add some kind of "claim-to-tag mapping" functionality to OIDC IDPs, so that we could have role session tags based on claims in OIDC tokens issued by GitHub Actions. That hasn't happened yet, but today I learned (thanks to this comment and associated blog post by Daniel Jonsén) that the same outcome can be achieved by using AWS Cognito identity pools as an intermediary.
GitHub Actions has supported using OIDC tokens for about 15 months now. It is a much better way of providing AWS credentials to workflows than creating IAM users and storing long-lived access keys in GitHub Actions secrets.
One issue holding back larger organisations from adopting this solution is the lack of useful granular controls. I touched on this in an earlier article AWS IAM OIDC IDPs need more controls.
In my post AWS federation comes to GitHub Actions I wrote about GitHub Actions' new ability to federate access into AWS (and other clouds) via OpenID Connect. This is really great, much better than the prior state of affairs, but needs improvement on the AWS side.
At the time of writing, this functionality exists but has yet to be announced or documented. It works, though!
EDIT: Here is the functionality on the GitHub roadmap.
GitHub Actions has new functionality that can vend OpenID Connect credentials to jobs running on the platform. This is very exciting for AWS account administrators as it means that CI/CD jobs no longer need any long-term secrets to be stored in GitHub.