Bug 1827364
Summary: | Update IngressController Docs for Http/2 Coalescing Limitations | ||
---|---|---|---|
Product: | OpenShift Container Platform | Reporter: | Daneyon Hansen <dhansen> |
Component: | Networking | Assignee: | Andrew McDermott <amcdermo> |
Networking sub component: | router | QA Contact: | Hongan Li <hongli> |
Status: | CLOSED ERRATA | Docs Contact: | |
Severity: | medium | ||
Priority: | high | CC: | aos-bugs, bbennett, scuppett |
Version: | 4.5 | ||
Target Milestone: | --- | ||
Target Release: | 4.6.0 | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Release Note | |
Doc Text: |
To enable HTTP/2 ALPN on a route it requires a custom (non-wildcard) certificate. This prevents connection coalescing by clients, notably web browsers. We do not support HTTP/2 ALPN on routes that use the default certificate because of the risk of connection re-use/coalescing. Routes that do not have their own custom certificate will not be HTTP/2 ALPN-enabled on either the frontend or the backend.
If a wildcard certificate is used and shared by multiple HTTP/2 enabled routes (which implies ALPN) then clients (i.e., notably browsers) are at liberty to reuse open connections. This means a client can reuse a connection to another route and that is likely to fail. This behaviour is generally known as connection coalescing.
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2020-10-27 15:58:27 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Daneyon Hansen
2020-04-23 18:05:53 UTC
Setting target release to current development version (4.5) for investigation. Where fixes (if any) are required/requested for prior versions, cloned BZs will be created when appropriate. Moving to 4.6 as not a release blocker or an upgrade blocker. This is a change for the API docs. I’m adding UpcomingSprint, because I was occupied by fixing bugs with higher priority/severity, developing new features with higher priority, or developing new features to improve stability at a macro level. I will revisit this bug next sprint. I’m adding UpcomingSprint, because I was occupied by fixing bugs with higher priority/severity, developing new features with higher priority, or developing new features to improve stability at a macro level. I will revisit this bug next sprint. I’m adding UpcomingSprint, because I was occupied by fixing bugs with higher priority/severity, developing new features with higher priority, or developing new features to improve stability at a macro level. I will revisit this bug next sprint. should update https://github.com/openshift/cluster-ingress-operator/blob/master/manifests/00-custom-resource-definition.yaml as well? when running command "oc explain ingresscontrollers.spec.defaultCertificate" it doesn't contain the HTTP/2 coalescing limitation. see: $ oc explain ingresscontrollers.spec.defaultCertificate KIND: IngressController VERSION: operator.openshift.io/v1 RESOURCE: defaultCertificate <Object> DESCRIPTION: defaultCertificate is a reference to a secret containing the default certificate served by the ingress controller. When Routes don't specify their own certificate, defaultCertificate is used. The secret must contain the following keys and data: tls.crt: certificate file contents tls.key: key file contents If unset, a wildcard certificate is automatically generated and used. The certificate is valid for the ingress controller domain (and subdomains) and the generated certificate's CA will be automatically integrated with the cluster's trust store. The in-use certificate (whether generated or user-specified) will be automatically integrated with OpenShift's built-in OAuth server. @Hongan, I just pushed https://github.com/openshift/cluster-ingress-operator/pull/442 to bring the https://github.com/openshift/api/pull/654 changes into ingress operator. https://bugzilla.redhat.com/show_bug.cgi?id=1827364#c9 should pass after PR 654 merges. Marked UpcomingSprint since it's unlikely that https://github.com/openshift/cluster-ingress-operator/pull/442 merges by tomorrow. The PR https://github.com/openshift/cluster-ingress-operator/pull/442 has been merged to https://openshift-release.apps.ci.l2s4.p1.openshiftapps.com/releasestream/4.6.0-0.nightly/release/4.6.0-0.nightly-2020-08-25-204643, so change the target release back to 4.6. verified with 4.6.0-0.nightly-2020-08-27-005538 and issue has been fixed. $ oc explain ingresscontrollers.spec.defaultCertificate KIND: IngressController VERSION: operator.openshift.io/v1 RESOURCE: defaultCertificate <Object> DESCRIPTION: defaultCertificate is a reference to a secret containing the default certificate served by the ingress controller. When Routes don't specify their own certificate, defaultCertificate is used. The secret must contain the following keys and data: tls.crt: certificate file contents tls.key: key file contents If unset, a wildcard certificate is automatically generated and used. The certificate is valid for the ingress controller domain (and subdomains) and the generated certificate's CA will be automatically integrated with the cluster's trust store. If a wildcard certificate is used and shared by multiple HTTP/2 enabled routes (which implies ALPN) then clients (i.e., notably browsers) are at liberty to reuse open connections. This means a client can reuse a connection to another route and that is likely to fail. This behaviour is generally known as connection coalescing. The in-use certificate (whether generated or user-specified) will be automatically integrated with OpenShift's built-in OAuth server. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (OpenShift Container Platform 4.6 GA Images), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:4196 |