-
Feature Request
-
Resolution: Unresolved
-
Normal
-
None
-
openshift-4.16, openshift-4.17, openshift-4.18, openshift-4.19
-
None
-
Product / Portfolio Work
-
None
-
False
-
-
None
-
None
-
None
-
-
None
-
None
-
None
-
None
-
None
1. Proposed title of this feature request
Support for chaining an Azure Gateway Load Balancer (GWLB) with the OpenShift Load Balancer managed by the Ingress Controller
2. What is the nature and description of the request?
We would like to request support for chaining an Azure Gateway Load Balancer (GWLB) with the OpenShift Load Balancer managed by the Ingress Controller, similar to the AKS use case described in https://github.com/Azure/AKS/issues/4345.
This feature is critical to enable transparent inspection of ingress traffic by third-party Network Virtual Appliances (NVAs) acting as firewalls before the traffic reaches OpenShift workloads.
3. Why does the customer need this? (List the business requirements here)
We aim to deploy third-party NVA (e.g., Palo Alto) in front of OpenShift ingress to inspect and validate incoming traffic.
The GWLB should be transparently chained to the frontend IP of the OpenShift-managed Load Balancer.
Requirements
- Ingress Controller Custom Resource Support:
The IngressController CRD should allow referencing a Gateway Load Balancer directly in its configuration (e.g., via loadBalancer.gatewayLoadBalancer or similar field).
- Cross-Subscription and Cross-Resource Group Support:
The GWLB may reside in a different Azure subscription and/or resource group than the OpenShift cluster. This chaining should be supported and documented.
- Transparent Mode:
The GWLB should operate in transparent mode, ensuring no changes are required in the application or ingress routing logic.
- When using Openshift with short terms credentials, associated Azure identity will require additional permissions to consume this GWLB, especially from different RG & Subscription, but this can be added independently from ccoctl setup at cluster creation
- K8s LB services (independently from ingress controller) should also support such feature through dedicated annotation (as specified in github issue above), and I guess this would be a prerequisite to integration in IngressController
4. List any affected packages or components.
- Ingress Controller
- API Server