[sns] add sns service trust to key when subscribing to an encrypted queue

[skinny85]

When using Bucket Notifications with SQS (so, something like bucket.onObjectCreated(queue)), in the case the Queue is encrypted with a KMS Key, we correctly trust the S3 Service Principal in the Key's Resource Policy.

We need to do something similar in the case of an SNS subscription to an encrypted SQS Queue (so, topic.subscribeQueue(queue)) - the Key should trust the SNS Service Principal in that case.

[github-actions]

This issue has not received any attention in 1 year. If you want to keep this issue open, please leave a comment below and auto-close will be canceled.

[MrArnoldPalmer]

Keeping open 👍🏻

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.

[HansFalkenberg-Visma]

I have spent some time looking into this and will summarize my findings here for ease of discovery (this was my first google hit).

There are two duplicates of this issue:
#11122
#12120

Related issue to warn that the KMS key cannot get the necessary policy if it is an AWS managed key:
#19796

This issue (#2504) was
implemented by #14960
merged in ccc2e30 and
released in https://github.com/aws/aws-cdk/releases/tag/v1.111.0
on July 2nd 2021.
All v2 releases (except pre-releases v2.0.0-rc.11 and older) have the fix.

There is also a duplicate attempted implementation:
#12146

That PR has some interesting comments about restricting CMK access by SourceArn, which is the reason I started looking into this. I had defined my CMK policy correctly with a condition on the subscribe SNS Topic ARN being the source, and was surprised when the L3 magic added a more permissive statement allowing any SNS service in the world access to my CMK.

Apparently this is because CMK access couldn't be restricted when #14960 was implemented. Now it can, and it should be a trivial change for which I created this issue:
#20339

[HansFalkenberg-Visma]

Also useful to know:
If your SNS Topic messages aren't reaching their destination (SQS in this case), you can enable delivery status logging and get a clue as to the cause in a CloudWatch log group. See https://docs.aws.amazon.com/sns/latest/dg/sns-topic-attributes.html#topics-attrib

CloudFormation (and thus CDK) does not support enabling delivery status logging, but it's coming: aws-cloudformation/cloudformation-coverage-roadmap#66

The error when CMK policy isn't right is

{
  "ErrorCode": "KMS.AccessDeniedException",
  "ErrorMessage": "null (Service: AWSKMS; Status Code: 400; Error Code: AccessDeniedException; Request ID: 187caab5-970a-49d9-836f-a12cb1e94796; Proxy: null)",
  "sqsRequestId": "Unrecoverable"
}