I've been writing software for 25 years, and been getting paid for the last 20. My AWS account will be turning 18 this September, and it should be quite the celebration. If I may toot my own horn: I've got pretty good at writing and deploying software in that time - to the point that you're actually spending your time reading this blog. All this, and the release of Opus 4.5 in November 2025 hit me like a tonne of bricks. My value-add (as I knew it) would soon be over.
AWS principal tags are useful for fine-grained access control. As an organisation administrator, you can craft service control policies (SCPs) that only allow tagged roles to call sensitive APIs. The problem then becomes: how do you guarantee that the tags are legitimate? This is where resource control policies (RCPs) come in handy - I provide a demonstration of them in this blog post, and an example of what you can achieve with the trustworthy tags in place.
Athena is one of my favourite AWS services. Though it's marketed as a big data service, it is useful in many other scenarios. Sometimes I use it as a "grep through unstructured logs in S3" and other times I use it to query CloudTrail logs - but this latter use case is likely better served by CloudTrail Lake nowadays. Today, I'll show how it can be used for querying Terraform state stored in S3.
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.
Back in November last year, I wished for the ability to filter
CloudTrail data events by the requesting principal's ARN. Two days later, my wish
was almost granted: CloudTrail launched the ability to filter on userIdentity.arn
for CloudTrail lakes but not trails. And now it seems my wish has almost
completely come true: the functionality has rolled out to trails as well.
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".