Document URL: https://docs.openshift.com/container-platform/4.5/installing/installing_bare_metal/installing-bare-metal.html#network-topology-requirements https://docs.openshift.com/container-platform/4.5/installing/installing_vsphere/installing-restricted-networks-vsphere.html#network-topology-requirements https://docs.openshift.com/container-platform/4.5/installing/installing_ibm_z/installing-restricted-networks-ibm-z.html#network-topology-requirements Section Number and Name: - Network topology requirements Describe the issue: - Load balancing SSL Bridge/Re-encrypt termination is likely to break mTLS for the OAuth component, unless a mechanism is put in place to validate client certificates. Suggestions for improvement: - SSL Passthrough requirement for API and Ingress should prevail and SSL Bridge/Re-encrypt should be (likely, temporarily) removed, at least until a more fine-grained list of load balancing requirements (and supported SSL/TLS Terminations) is made available following this [0] parallel Documentation bug. --- [0] Lack of information on prerequisites for external load balancers - https://bugzilla.redhat.com/show_bug.cgi?id=1809694
The doc PR looks good, moving to verified. thanks.
Current documentation contains requested changes: https://docs.openshift.com/container-platform/4.9/installing/installing_bare_metal/installing-bare-metal.html https://docs.openshift.com/container-platform/4.9/installing/installing_ibm_z/installing-ibm-z-kvm.html#installation-load-balancing-user-infra_installing-ibm-z-kvm https://docs.openshift.com/container-platform/4.9/installing/installing_vsphere/installing-restricted-networks-vsphere.html#installation-load-balancing-user-infra_installing-restricted-networks-vsphere
Hi, I am reopening this bug because the documentation doesn't have the changes in the PR. Not sure why the PR was closed, but it was premature. Can you please have a look?
The latest git clone still shows the same lines, did we miss it? [root@vm252-124 openshift-docs]# git grep 'SSL Bridge mode' modules/installation-load-balancing-user-infra.adoc: ** 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. modules/installation-load-balancing-user-infra.adoc: ** 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 ingress routes. [root@vm252-124 openshift-docs]#
i would argue against explicitly not allowing ssl re-encrypt for oauth. i know of a couple clients who have re-encrypt WAFs in front of their wildcard comains, including the oauth name, and the only trick to make it work was being sure to inject sni headers into the re-encrypt. at least for those couple of clients we haven't seen any negative effects. if this is ultimately the way we are going, i worry about clients who wont see this specific change in requirements and suddenly their clusters will not be in compliance.
Ian the main problem is not SNI but the fact that the certificates presented by the front load balancer must be consistent with what the cluster expects. OCP4 manages a number of certificates, some of which are customizable and some of them aren't, and the system expects that, once it sets a certificate somewhere, that change is in effect without any external intervention. Besides, the list of system routes (which are not for external consumption) and their certificates settings might change between versions. If your customers have not had any problem with this setup, it has been a combination of them having been very careful with keeping this certificate consistency (which is very good on their side) plus pure luck. However, I have seen already situations with customers where this hasn't been the case and where it was difficult to troubleshoot that there was some certificate mismatch due to reencryption in the main load balancer.
Pablo, understood. thanks for the clarification.
Pablo, will this supportability requirment apply only to the oauth dns entry or for the entire wildcard dns entry? i understand making it apply to the oauth dns entry, but making it apply to the entire wildcard precludes the option of using a WAF for client applications using the wildcard dns.
It would impact the whole default wildcard. However, an additional ingress controller with a different wildcard should have no problem (you would need proper SNI config for passthrough routes to work, but I understand that's not a problem for your customer). The key is that re-encryption doesn't impact any of the system routes (either current or that might exist in future versions).
could we not ammend the documentation to say that if putting a WAF (or similar re-encyrpt) in front of the wildcard that for these specific system routes, like oauth, that those dns entries need to bypass the re-encyprt. this way people can still put a WAF in front of their default wildcard without having to deal with setting up another, but then the system routs that dont like the re-encrypt can have specific dns entires that bypass the re-encrypt and go direct to the routers.
The problem with that approach is that system routes may change without previous notice, so that approach is not feasible.
Lisa, Is this bug fix applicable for 4.8.z+ versions, if yes, then please work on the bug fix, else close this bug at the earliest.
It is applicable to all versions, so setting to latest version accordingly.
OpenShift has moved to Jira for its defect tracking! This bug can now be found in the OCPBUGS project in Jira. https://issues.redhat.com/browse/OCPBUGS-8817
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days