Feature Overview

Customers want to do application layer inspection at the load balancer (LB) in front of the *apps default IngressController (IC). SSL termination at the LB is not intended so re-encryption is done from the load balancer to *.apps; this is known as "SSL bridging." There are several downsides to doing this in front of the *.apps ; some system routes break, such as oAuth, if re-encryption does not send the Server Name Indicator (SNI).  Also, anything requiring mTLS will not work.  In other words, OCP system routes (which use *.apps) have requirements that limit, or complicate, what customers can do in front of their applications which by default use the same route.  

Additionally, there is currently a documentation bug to change the following statement which is published in our installation guide from:

Layer 4 load balancing only. This can be referred to as Raw TCP, SSL Passthrough, or SSL Bridge mode. If you use SSL Bridge mode, you must enable Server Name Indication (SNI) for the API routes.

to this:

Layer 4 load balancing only. This can be referred to as Raw TCP or SSL Passthrough mode.

 Note the elimination of SSL bridge support.  We have three support exceptions (linked) because customers noticed this proposed change.  This was discussed during the 10-January-2023 Control Plane Architecture meeting and it was agreed that this docs change should take place to accurately reflect what we test, which does not include SSL bridging.  

At the same control plane architecture meeting, it was agreed that adding a 2nd ingress controller for SSL bridging is the best way to satisfy this ask.  

Requirements

1. Test and document the addition of an ingress controller.  This should be possible with the current product, but is not well documented. See the links for resources.
2. Test and document Ingress Controller sharding with namespace labels to direct apps that need SSL bridging to the 2nd ingress controller
3. Update documentation with the caveat that we can't name all the things, like mTLS, that won't work with SSL bridge mode.  The customers assumes the risk.  

Risks

If we can't truly test SSL bridging, then we have to back off on suggesting that we support it.  We can still perform the requirements #1-#2 above and suggest that customers are welcome to use the 2nd ingress controller for alternative routes but Red Hat is not responsible for any apps that don't work unless the issue can be re-produced with SSL passthrough (our default).