-
-
Notifications
You must be signed in to change notification settings - Fork 4.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: Account for cases when we are using an existing cloudwatch log group for flow logs #1118
base: master
Are you sure you want to change the base?
Conversation
Hiya @antonbabenko, apologies for poking, but is there anything I can do to help ferry this along? Am I missing anything here? |
@antonbabenko / @bryantbiggs -- sorry to re-bump, but I'd love to get this upstream. Please let me know if I'm missing anything critical here! |
This PR has been automatically marked as stale because it has been open 30 days |
This is still relevant ✌️ |
This PR has been automatically marked as stale because it has been open 30 days |
✨ still valid! ✨ |
This PR has been automatically marked as stale because it has been open 30 days |
Still relevant. |
Description
When generating the flow log group ARNs to include in the policy, if we are using a pre-existing log group, take that into account and use the destination ARN passed in as a variable, rather than assuming that we created a log group ourselves.
Motivation and Context
Since 5.12.0, if you are using an existing CloudWatch Log Group for your flow logs destination ARN, this module tries to update the relevant IAM policy with an invalid policy document, which fails. See PR #1088.
This fixes #1117
Breaking Changes
None
How Has This Been Tested?
examples/*
to demonstrate and validate my change(s)examples/*
projectsI have tested this in our own workspaces using a fork of this module -- I am happy to go further with the examples here if needed/desired.
pre-commit run -a
on my pull request