tl;dr: Search CloudTrail for instances of AssumeRole with
additionalEventData.explicitTrustGrant == false. These will yield results
for role assumptions that aren't permitted by the trust policy, i.e. the
ones that are going to surprise you - and violate your invariants like "role
session names will always be an employee's email address".
AWS CloudShell got a new capability in January 2024: running Docker containers. This piqued my curiosity because Docker-in-Docker usually implies privileged containers, and I have previously used that to escape CodeBuild onto the parent EC2 instance. I wanted to know if the same could be done in CloudShell - and how its AWS credential system worked (the environment inherits the user's credentials, unlike CodeBuild). The short answer is "it can be done", and this post goes into a) how to do it and b) documenting what I could learn about the inner workings of CloudShell.
This article has been in my drafts for 380 days. It's probably time I published it,
before I forget even more details about how it works. ~A few~ 380+ days ago, I
published ima.ge.cx. It's a web frontend for browsing the contents
of Docker images. It's like a less powerful version of dive that
doesn't require you to pull images locally. It's also worth noting that there's
a much more feature-rich (and likely less buggy) site that does a similar thing:
Registry Explorer.
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.
A few years ago, I wrote about determining AWS account IDs from AWS
access keys, i.e. those strings that begin with AKIA or ASIA. It's also
possible to determine information from other AWS IAM unique IDs, specifically
these two from the table in Amazon's docs.
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.
Last week AWS published a blog post advising that the go1.x Lambda
runtime will be deprecated and people should migrate to provided.al2. I was
already using the newer runtime, but I also learned from the blog post that AWS
SAM can now build Go Lambda functions for the newer runtime - no more Makefiles
required!
I switched from BuildMethod: makefile to BuildMethod: go1.x and noticed that
my Lambda packages were now twice the size. This means slower cold starts and
slower deployments - especially from my laptop in Australia. I also noticed that
my CI pipelines were slower because every commit was causing Lambda updates, even
when no code had changed.
Today I was experimenting with CloudTrail data events for Lambda invocations, because I learned that as of 2021, these data events log the ENI ID used by a Lambda function invocation.
tl;dr: You can now pass an IAM role to every EC2 instance in your account + region.
On Feb 17th 2023, AWS Systems Manager released Default Host Management Configuration.
This is a way to use Systems Manager on all your EC2 instances: they don't need
ssm:* permissions in their instance profiles, nor do they even need an instance
profile at all.
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.