Here’s a refined version of the problem description you can use for your start-up call:
During the process of implementing the ConstructInternalRouteWhiteListRule, we encountered an issue with how it interacted with an existing rule. The objective of this new rule was to restrict access to internal IPs when a specific route containing /internal/* was detected in the request path.
Initially, we had an existing rule in place that only allowed access to APIs if the request came from an internal route, effectively blocking all other external routes. However, as part of our testing, this rule was expected to be removed as the application moves to production.
When I attempted to test the newly created rule by removing the existing rule, we encountered a problem. Since the Web Application Firewall (WAF) has a default action of blocking all incoming requests unless explicitly allowed, without the existing rule, all incoming requests were blocked. The new rule alone was insufficient to process requests because it was set up to allow access based on specific IPs and paths, but no complementary rule existed to allow other non-internal routes.
This situation led us to realize that we needed to create two distinct rules:
One rule that allows non-internal routes, bypassing the need for IP checking.
Another rule that permits access to internal routes only if the request originates from an approved IP set.
These two rules would ensure a balance between internal and external access, with the proper fallback to block unwanted requests based on specific conditions.
This explanation provides clarity on the situation and decision-making process regarding the WAF rule setup and the need for the two new rules. Let me know if any adjustments are needed!
Here’s a refined version of the problem description you can use for your start-up call:
During the process of implementing the ConstructInternalRouteWhiteListRule, we encountered an issue with how it interacted with an existing rule. The objective of this new rule was to restrict access to internal IPs when a specific route containing /internal/* was detected in the request path.
Initially, we had an existing rule in place that only allowed access to APIs if the request came from an internal route, effectively blocking all other external routes. However, as part of our testing, this rule was expected to be removed as the application moves to production.
When I attempted to test the newly created rule by removing the existing rule, we encountered a problem. Since the Web Application Firewall (WAF) has a default action of blocking all incoming requests unless explicitly allowed, without the existing rule, all incoming requests were blocked. The new rule alone was insufficient to process requests because it was set up to allow access based on specific IPs and paths, but no complementary rule existed to allow other non-internal routes.
This situation led us to realize that we needed to create two distinct rules:
One rule that allows non-internal routes, bypassing the need for IP checking.
Another rule that permits access to internal routes only if the request originates from an approved IP set.
These two rules would ensure a balance between internal and external access, with the proper fallback to block unwanted requests based on specific conditions.
This explanation provides clarity on the situation and decision-making process regarding the WAF rule setup and the need for the two new rules. Let me know if any adjustments are needed!