(aws-event-targets): Clarify that adding an imported SNS Topic as an event target does not set required permissions

[SamStephens]

Describe the bug

aws_events_targets.SnsTopic implicitly grants publish permissions on the Topic to the EventBus service principal.

However, this silently is a no-op when the Topic is imported.

This is a particularly painful experience because there's very little visibility as to what is going on. All you see is FailedInvocations for your EventBus Rule, with no indication as to what is going on.

Expected Behavior

I expected using aws_events_targets.SnsTopic to wire up a working integration.

Current Behavior

My integration didn't work because required permissions were not granted.

Reproduction Steps

Declare an SNS Topic in one stack. In another stack, import and use that Topic in a rule.

        topic = aws_sns.Topic.from_topic_arn(
            scope=self,
            id="Alarm",
            topic_arn='your-topic-arn',
        )

        rule = aws_events.Rule(
            scope=self,
            id="FindingNotification",
            enabled=True,
            schedule=aws_events.Schedule.rate(Duration.minutes(1)),
            targets=[
                aws_events_targets.SnsTopic(
                    topic=topic ,
                )
            ],
        )

You'll see your rule has a failed invocation every minute.

Possible Solution

If I understand how permissions are granted via Resource Policy, it's either not possible or very complex to grant access to a Topic that's not declared in our current stack. However the silent failure is confusing, and in an ideal world you'd opt into having to set up permissions yourself. Something like:

        rule = aws_events.Rule(
            scope=self,
            id="FindingNotification",
            enabled=True,
            schedule=aws_events.Schedule.rate(Duration.minutes(1)),
            targets=[
                aws_events_targets.SnsTopic(
                    topic=topic ,
                    configure_permissions=False,
                )
            ],
        )

And without setting configure_permissions to False, synthesis would fail for an imported Topic.

Additional Information/Context

No response

CDK CLI Version

2.79.1 (build 2e7f8b7)

Framework Version

2.79.1

Node.js Version

v16.18.1

OS

Ubuntu (Windows Subsystem for Linux)

Language

Python

Language Version

3.9.7

Other information

No response

[peterwoodworth]

I think the better solution here is to clearly call this out in the targets.SnsTopic docs, rather than introducing a prop

[Zishanwang1992]

I think we can focus on auditing/logging improvement, for example the reason why the rule fails. Not sure if it can be found from Cloudtrail or CloudWatch log.

If the two resources are defined in two separate stacks, it makes sense to me to have "no-op" to comply with separate of concern.

[github-actions[bot]]

⚠️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.