aws-solutions / aws-waf-security-automations

This solution automatically deploys a single web access control list (web ACL) with a set of AWS WAF rules designed to filter common web-based attacks.
https://aws.amazon.com/solutions/aws-waf-security-automations
Apache License 2.0
835 stars 358 forks source link

fix: parameterise the workgroups to make stack more flexible #228

Closed peterabbott closed 1 year ago

peterabbott commented 1 year ago

Issue #150

Adds unique workgroup names to make the stacks more flexible and be able to deploy multiple stacks in one region. The reason here is to be able to test updates to a (secondary) WAF in a target region before switching traffic on to an updated version.

aijunpeng commented 1 year ago

Thanks for the PR. We decided not to support multiple deployments of the out-of-box solution in the same account/region for multiple reasons including security, service limit, etc. We can revisit the request. Can you please list all the reasons why you would like to have multiple deployments? In the time being, please continue to customize the source code shall you need to do so.

About the PR, we don't recommend to add stack name as part of the Athena workgroup name because workgroup name has a limit of 128 chars (https://docs.aws.amazon.com/athena/latest/ug/workgroups-settings.html) therefore this change will break the solution when customers use a long stack name.

UUID is generated per solution deployment and updating existing stack shouldn't update the resources if no other stack configuration changes will trigger the resource update.

peterabbott commented 1 year ago

Thanks for the PR. We decided not to support multiple deployments of the out-of-box solution in the same account/region for multiple reasons including security, service limit, etc

We use multiple deployments to be able to test updates in a region before switch traffic, so have a primary and backup instances in each region. It allows us test updates to configuration without impacting the main traffic.

UUID is generated per solution deployment and updating existing stack shouldn't update the resources if no other stack configuration changes will trigger the resource update.

This is not what we are seeing. Because the UUID is generated and then past in to things like the lambda config they get a new deployment each time a stack update is executed.

workgroup name has a limit of 128 chars

There many other places this applies, to even shorter limits. Bucket names ETC. It is just something we have to accept when creating any stack.

aijunpeng commented 1 year ago

Are u seeing the update in the out-of-box solution or customized code? In the out-of-box solution, the lambda function that creates the UUID will only be triggered at stack creation.

peterabbott commented 1 year ago

Are u seeing the update in the out-of-box solution or customized code? In the out-of-box solution, the lambda function that creates the UUID will only be triggered at stack creation.

Was the out-of-box, but I will check again. I was seeing Cloudformation show all the lambdas getting an update each time the stack is updated was applied.

We have for now forked and customised a couple of settings that couldn't be using the input parameters.