Add logs:TagLogGroup permission to the log group role

[drewdresser]

This role is used by the custom resource to create log groups. Something seems to have changed in the CDK log implementation or in the CW logs creation which is now requiring this IAM action to be in the policy.

See #1079 for more information.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[Brian969]

LGTM

[Brian969]

Very much appreciate the contribution, Thanks!

[Brian969]

To avoid any impact, all customers must upgrade to v1.5.5. Anything that results in a new CloudWatch Log group being created will cause customer SM's to fail including but not limited to: new installations, upgrades, new sub-account creation, addition of R53 resolvers or zones, addition of new VPC's with flow logs enabled, and many more. While impacts were initially limited to us-east-1, they have extended globally.

[Brian969]

Potential temporary manual workaround (for the tagging issue):

• in any account where the ASEA needs to create new log groups
• when the state machine fails, go into the sub-account causing the failure
• In IAM, find the IAM role which caused the failure (i.e. from the logs or from CloudTrail)
  • i.e. ASEA-Test1-Phase-1-CustomLogsLogGroupABC-xxx
• edit the roles inline policy, adding "logs:TagLogGroup" to the actions section of the policy
• rerun the SM, it will fail in the next phase (i.e. if it's a new account creation)
• repeat until SM completes
  NOTES: these manual updates are likely to be overwritten