Skip to content

AWS

Querying Terraform state with AWS Athena

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.

Federating into Azure, GCP and AWS with OIDC

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.

CloudTrail wish: almost granted

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.

CloudFront-triggered S3 data event formats

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.

CloudTrail wishlist: filtering by principal ARN

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!

Surprising behaviour in AWS web console session duration

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.

When AWS invariants aren't [invariant]

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

Deep dive into AWS CloudShell

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.

How ima.ge.cx works

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.