A common practice is to use org-wide cloudtrails. These trails write events to s3 nested under account number. As it stands today, there is no easy way to selectively ingest only specific accounts.
Feature
We would like to selectively ingest cloudtrail data from aws accounts in an org-trail s3 bucket by way of configuring s3 bucket notifications with prefixes and pointing them to SNS. Currently the plugin expect SNS notifications directly from cloudtrail.
Alternatives
Additional context
Looking at the snsMessage struct, it appears that the plugin will only ingest directly from cloudtrail. The proposal is to introduce a flag/param that can be used to direct the plugin to read SNS originating from s3.
leogr
commented
2 years ago
Motivation
A common practice is to use org-wide cloudtrails. These trails write events to s3 nested under account number. As it stands today, there is no easy way to selectively ingest only specific accounts.
Feature
We would like to selectively ingest cloudtrail data from aws accounts in an org-trail s3 bucket by way of configuring s3 bucket notifications with prefixes and pointing them to SNS. Currently the plugin expect SNS notifications directly from cloudtrail.
Alternatives
Additional context
Looking at the snsMessage struct, it appears that the plugin will only ingest directly from cloudtrail. The proposal is to introduce a flag/param that can be used to direct the plugin to read SNS originating from s3.