Feature Overview

Separate internal OpenShift routes that have unique requirements such as mTLS from the default OCP ingress. This pattern is already used for the api.<cluster_name> endpoint, but not replicated for oauth-openshift.apps.<cluster_name>. This design decision creates confusion and complexity in implementation, maintenance and support of OCP clusters. We should give customers the flexibility to manage their application traffic however they desire outside of OCP on the *.apps domain and break the dependency on it for underlying internal OpenShift components whenever possible.

Goals

Red Hat would benefit from this feature by:

• Less ambiguity in the support requirements
• Fewer issues where oauth traffic is disrupted by upstream network devices and design
• Consistency in design where the applications that we support and maintain can have their own requirements outside of those the customer maintains 

Customer Operations Teams would benefit from this feature by:

• Simplifying the documentation and installation instructions (app ingress vs api ingress)

Customer Security Teams would benefit from this feature by:

• Ability to implement policies (organizational or mandated) to application traffic that are needed with the strictest possible rules without impacting internal OCP functionality
• Greater visibility into traffic flows on the edge with decryption, inspection, and re-encryption of data in flight
• Simplified approval processes for OCP architecture with a clear delineation between application traffic and authorization traffic

Requirements

A list of specific needs or objectives that a Feature must deliver to satisfy the Feature. Some requirements will be flagged as MVP. If an MVP gets shifted, the feature shifts.  If a non MVP requirement slips, it does not shift the feature.

(Optional) Use Cases

Customer is federally mandated to decrypt and inspect all web application traffic at the edge

Customer wants to leverage a commercial Web Application Firewall like provided by CloudFlare

Customer’s policy/desire is to have SSL termination on the LB

Assumptions

The documentation should be explicit in what we can support for the default ingress. If that support is less than re-encryption support, or requires extensive customization it will impact our ability to sell to customers in regulated environments.

Customer Considerations

Customers, particularly in any sort of regulated environment (government, financial, healthcare, etc) often have security requirements that often require network inspection and SSL termination+reencryption outside of OpenShift.