toolkit: surface potentially risky changes and enforce confirmation

[eladb]

"cdk diff" should surface to the user any changes to IAM permissions in a very explicit way. Users should be able to see exactly which permissions were added or removed from their app.

This is particularly important when using 3rd party construct libraries, it's important to ensure that any permissions changes are clearly visible to the user.

We should also consider requiring an explicit interactive approval for permission changes in "cdk deploy". Something like:

$ cdk deploy
Please confirm that the following permissions will be added:
- sqs:SendMessage on <ARN> will be granted to <PRINCIPAL>
- dynamodb:PutObject on <ARN> will be granted to <PRINCIPAL>
Please confirm (Y/N) or use -y for non-interactive experience [N]: 

[RomainMuller]

That's beautiful in theory but coming up with messaging that is clear in the general case will be challenging (NotPrincipal, NotAction, what does * on <ARN> will be granted to <PRINCIPAL> mean - do we expand to the list of all valid actions? ...).

Also, this brings you zero benefits if you're not using the cdk toolkit for deploying...

[eladb]

clear in the general case

I don't think we need "general" messaging, I think we need deep understanding of IAM policies and very specific messaging as to what has changed. It's going to be a set of heuristics that we understand and we can always fall back to showing a nice JSON diff of statements or fragments we don't understand.

Also, this brings you zero benefits if you're not using the cdk toolkit for deploying...

I think this should actually part of the synthesizer, which is needed whether you deploy via the toolkit or not.

[rix0rrr]

Extra highlight (summary) of cross-account (or even public) permissions.

[rix0rrr]

My plan was to annotate all attributes that encode sensitive data (IAM policies and Security Group) in the spec, half-manually and half-automatically.

We can then look up the annotations for every attribute after generating the diff, and then doing something intelligent with the diffs based on the annotation type (such as collect into a summary table).

I have some code around this, let me know if you want it.

[rix0rrr]

@eladb I'm ready to pick this up again if you're busy doing other things.

My plan is to add a summary table to every deployment that looks somewhat like this:

	Resource	Actions	Principal	Other
+	${/stack/Construct/MyResource.Arn}/*	s3:GetObject, s3:PutObject	${/stack/Construct/MyRole.Arn}	Condition: { ... }
+	*	logs:CreateLogs	${/stack/Construct/MyLambda/Role.Arn}
+	${/stack/Queue.Arn}	sqs:PublishMessages	arn:aws:us-west-5:123456789012:root	Condition: { ResourceArn:{ arn:aws:us-west-5:123456789012:topic:HelloTopic }}
-	${/stack/SomeResource.Arn}		arn:aws:us-west-5:123456789012:root	NotAction: ["re:Source", "re:Delete"]

The diff will be done before every deployment, and the table will be shown and needs to be acknowledged if there are differences in it.

[eladb]

Looks great @rix0rrr!

How are we going to handle acknowledgement in CI/CD? I sense we need some way to "store" the acknowledgement. Feels like a a more general purpose mechanism for "diff ack" that we can implement. Perhaps in a separate PR, so maybe in the meantime, this can just be in the output of "diff"?