Auditing your Substrate-managed AWS organization
One of the very first things Substrate does is to configure AWS CloudTrail with a single trail that covers all organization accounts in all regions. To access this wealth of data, assume the
Auditorrole in your audit account.
On the command line:
substrate assume-role -special audit
Or you can assume the role in the AWS Console via your Intranet's Accounts page.
In either case, the data you seek is in the
<prefix>-cloudtrail(substituting your chosen prefix as stored in
substrate.prefix) S3 bucket. You can download it to analyze locally or query it with Amazon Athena. The most straightforward way to proceed is by creating Athena tables for each AWS account; partition projection to cover the entire organization is unsolved.
Many tools have grown the ability to assume an IAM role in your AWS account to perform some auditing or monitoring feature on your behalf. To allow these into your AWS organization, create an assume role policy in
substrate.Auditor.assume-role-policy.jsonwith contents like this:
You can include as many principals as you'd like in the innermost list.
Every time you update this file, you'll need to re-run
substrate create-accountfor each of your service accounts.
This will authorize third-party principals to
sts:AssumeRoleusing the ARN of one of your Auditor roles and operate as you would there.
If allowing the third party organization-wide read-only access is too permissive, consider using
substrate create-roleto target certain accounts and grant exactly the permissions the third party requires.