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.

I say “almost” because it comes with a few caveats. I wished for a way to filter on the principal’s ARN, i.e. the field at userIdentity.sessionContext.sessionIssuer.arn. We can only filter on userIdentity.arn. These are mostly similar, but the latter drops the path (if any exists) on the IAM user/role. That’s a shame if you’ve neatly categorised all your human-assumable IAM roles under a /human/ path and hoped to only log their access to DynamoDB, S3, etc. Instead you have to hope that you are also using a pattern on the role name and match based on that.

That leads me to the second caveat: you can match on string prefixes and/or suffixes and use negation, but there is no pattern-matching. If you are using an organization-level trail and want to log all DynamoDB writes by a role called admin, I can’t see how to do that. You can’t match on arn:aws:sts::*:assumed-role/admin. You can’t use a suffix match on assumed-role/admin because the userIdentity.arn field also includes the role session name (which is often an email address, a timestamp or a random string). That makes it signficantly less useful if you have a lot of AWS accounts.

The CloudTrail console has an example Exclude AWS service-initiated events event selector, and it generates the following JSON. Notably the negated prefix match has a role session ARN without an account ID. I tried following this pattern and it didn’t work. An event selector with an account ID did match.

screenshot

I hope I’m missing something here, because this limits the utility of the new functionality in my eyes. Please reach out if so!