There are several ways that CloudFront can be configured with an S3 origin. There are functionality differences between them, but the focus in this blog post is how activity is represented in CloudTrail, specifically the differences in S3 data-level events for each CloudFront option.
UPDATE: My dream came true - almost. See follow-up post.
AWS re:Invent 2024 is fast approaching and there's usually a flurry of exciting new services and features for existing services launched around this time each year. I'll be there in person this year - come say hello if you are too!
Credentials for AWS IAM role sessions are short-lived. By default, they last for
one hour. When calling AssumeRole you can request a different duration by
passing a value between 900 (15 minutes) and 43200 (12 hours) in the
DurationSeconds parameter. Note that this API call will fail if you request
a session duration longer than is configured on the role itself (in the "max
sesson duration" property). These credentials can be used by the AWS CLI and
AWS SDKs.
You can also use these credentials to log into the AWS web console. You do this
by calling the GetSigninToken and Login endpoints of the AWS federation API.
AWS provides this documentation on how to do that. The first of these
endpoints (GetSigninToken) allows you to pass an optional SessionDuration
parameter. This acts as you might expect: it defines how long the web console
session will remain valid. What surprised me: you can start a 12 hour web
console session for a role that has a max session duration of 1 hour. The web
console session will outlive the credentials that were used to create it.
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.