(cloudtrail): Encryption key doesn't help set up policies correctly

[allquixotic]

Describe the feature

Setting up an event rule (AWS::Events::Rule) requires a tremendous amount of infrastructure beneath it, all configured in very precise and not very well documented ways, to be able to react to arbitrary API calls logged to CloudTrail.

CDK makes it much easier than CloudFormation, but it could still be easier. Specifically, I'd like the ability for the CloudTrail and/or Events modules of CDK to automatically configure the KeyPolicy of the AWS::KMS::Key that you create for encrypting the CloudTrail log bucket. This is really tricky to get right on your own.

Use Case

Here is my current code in Python:

mykey = kms.Key(self, "LogKey", alias="logkey")
trail = cloudtrail.Trail(self, "myCloudTrail", send_to_cloud_watch_logs=True, encryption_key=mykey)
rule = events.Rule(self, "rule", event_pattern=events.EventPattern(
  source=["aws.organizations"],
  detail_type=["AWS API Call via CloudTrail"],
  detail={
    "serviceEventDetails": {
      "createAccountStatus": {
        "state": ["SUCCEEDED"]
      }
    },
    "eventName": ["CreateAccountResult"]
  }
), targets= [
  targets.EventBus(events.eventBus.from_event_bus_arn(self, id="TargetEventBus", event_bus_arn="arn:aws:events:us-east-1:111111111111:event-bus/TargetEventBus"))])

Even with all this code, expressing the insanely simple idea of "run a Lambda function in a member account when a new account is created in the AWS Organization" is still not working. It fails when trying to create the AWS::CloudTrail::Trail with:

Resource handler returned message: "Invalid request provided: Insufficient permissions to access S3 bucket blahblah or KMS key arn:aws:kms:us-east-1:111111111111:key/(guid). (Service: CloudTrail, Status Code: 400, Request ID: guid, ...

And I haven't even shown the code for creating the event bus and Lambda function in the member account!

It's not the CDK's fault that the infrastructure for such a seemingly simple use case requires a degree in rocket science to successfully stand up, but CDK can certainly make this easier.

It seems the culprit of my code is either:

• The bucket, which automatically gets created by the CloudTrail CDK construct, doesn't have a sufficiently open bucket policy for CloudTrail itself to be able to access it (this seems unlikely); or:
• The bucket is fine, but the KMS Key's KeyPolicy was not adjusted by the subsequent code to ensure that CloudTrail and EventBridge can use the key as needed.

I've been studying the pure CloudFormation way to do all this for hours, and I still don't understand exactly what the KeyPolicy and BucketPolicy are supposed to be for this seemingly simple use case that can be expressed in one sentence. I wish CDK would just take care of it for me in a construct.

Proposed Solution

Enhance existing constructs, or create a new construct, to handle the design pattern here, and chop off all the boilerplate, so that the developer only has to concern themselves with the correct EventPattern and Targets for the EventBridge rule, and can completely abstract away the PhD-level machinations of permissions on the S3 bucket and KMS key to make this idea a reality.

Other Information

No response

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

CDK version used

2.24.1

Environment details (OS name and version, etc.)

RHEL 8 with Python 3.9

[rix0rrr]

I agree that the Trail construct could have helped you more here. Of course, today changing it to add that policy would be a risky change that would require a feature flag.

In the mean time, I would suggest adding a key policy yourself, stating that anyone allowed to write to that S3 bucket can encrypt using KMS:

key.grantEncrypt(new kms.ViaServicePrincipal('s3.amazonaws.com', new iam.AnyPrincipal()));

https://docs.aws.amazon.com/cdk/api/v1/docs/@aws-cdk_aws-kms.ViaServicePrincipal.html

Either that or:

key.grantEncrypt(new iam.ServicePrincipal('cloudtrail.amazonaws.com'));