Multiple HTTP Security Policy Sets Not Functioning as Expected

Products

• VMware Avi Load Balancer

Issue/Introduction

When configuring Virtual Services (VS) with multiple HTTP Security Policy Sets, access control rules are not applied as expected. Specifically, even when a client's IP address matches an "allow" rule in one policy set, it may still be blocked by subsequent "block" rules in other policy sets. This behavior prevents granular access control when using multiple policy sets.

Environment

 

• Avi ALB integrated with Kubernetes via AKO (OpenShift).
• Virtual Services configured with multiple HTTP Security Policy Sets.

 

Cause

Avi ALB processes all configured HTTP Security Policy Sets sequentially. If a client's request matches an "allow" rule in one policy set but also matches a "block" rule in a subsequent policy set, the "block" rule takes precedence, resulting in the connection being denied.

Resolution

To achieve the desired access control, it is recommended to consolidate all access rules into a single HTTP Security Policy Set with multiple rules. Within this single policy set, order the rules to ensure that the most specific "allow" rules are processed before more general "block" rules.

Example:

Instead of using separate policy sets for "ALLOW_FROM_NETWORK_A," "ALLOW_FROM_NETWORK_B," and "BLOCK_ALL," create a single policy set with rules like:

1. Allow specific IP addresses or networks.
2. Block all other traffic.

Additional Information

 

• Using a single policy set with IS_NOT_IN can be used to block specific IPs.
• The issue is related to the processing order of multiple policy sets.
• When multiple policy sets are applied to a Virtual Service, all policy sets are evaluated.
• If a client's request matches a "block" rule in any of the applied policy sets, the connection is denied, regardless of any "allow" rules in previous policy sets.
• For complex access control scenarios, consolidating rules into a single policy set provides better control and predictability.