CloudTrail addS3EventSelector wrongly documented and not working

[MichaelHindley]

https://github.com/awslabs/aws-cdk/blob/v0.24.0/packages/@aws-cdk/aws-cloudtrail/lib/index.ts#L202 is wrongly documented on https://awslabs.github.io/aws-cdk/refs/_aws-cdk_aws-cloudtrail.html?highlight=adds3eventselector, they have different signatures.

The second argument is an Enum, not an Object.

The first argument is not able to work with s3 buckets.

Trying to add an array of strings, for example:

trail.addS3EventSelector([bucketArn], cloudtrail.ReadWriteType.WriteOnly)

results in the error:

Value bucketArn for DataResources.Values is invalid. (Service: AWSCloudTrail; Status Code: 400; Error Code: InvalidEventSelectorsException;

If instead of bucketArn you supply arn:aws:s3::: it works, but that makes it so that you can only have a trail for all s3 buckets or for none of them.

If I go to the AWS Console and try to add the bucket manually, it works and seems to be the equivalent of checking the "Add all buckets in your account" checkbox.

This case is also not handled in the test https://github.com/awslabs/aws-cdk/blob/d7371f0f836ce8b0e08df1673672f904bde1cfe1/packages/%40aws-cdk/aws-cloudtrail/test/test.cloudtrail.ts.

If I can do anything else to help I am able to but I dont even know where to start debugging this internally!

[RomainMuller]

Hey @MichaelHindley - the issue (I mean beyond the fact the documentation and code disagree on the signature) is you cannot pass bucketArn as a prefix... You have to pass an object ARN prefix...

You'd get the correct behavior (I believe) by writing:

trail.addS3EvenetSelector([bucket.arnForObjects('')]);

It is impossible for the CDK to determine whether the value you pass in a prefix is valid or not, particularly in the case the value is not available at synthesis time (as in the example above - assuming bucket is defined in the CDK app - the object ARNs are the result of Fn::Joins).

[MichaelHindley]

Thank you very much!

bucket.arnForObjects('') did indeed result in the correct behaviour in this case :)