Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1727834

Summary: oauth didn't work with http2.0
Product: OpenShift Container Platform Reporter: xpflying
Component: apiserver-authAssignee: Standa Laznicka <slaznick>
Status: CLOSED WONTFIX QA Contact: scheng
Severity: low Docs Contact:
Priority: low    
Version: 4.1.0CC: amcdermo, aos-bugs, dhansen, gblomqui, lszaszki, mfojtik, mmasters, nagrawal, slaznick
Target Milestone: ---Flags: mfojtik: needinfo?
Target Release: 4.6.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: 4.5 LifecycleReset
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-08-31 14:00:11 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 xpflying 2019-07-08 10:23:16 UTC
Description of problem:
when haproxy router enable http2.0, the oauth service didn't work

Version-Release number of selected component (if applicable):
OpenShift Container Platform 4.1.4

How reproducible:


Steps to Reproduce:
1. oc set env deploy/router-default ROUTER_ENABLE_HTTP2=TRUE -n openshift-ingress
   enable HAProxy router HTTP/2 support.
2. open https://console-openshift-console.apps.xxx.example.com then redirect to https://oauth-openshift.apps.xxx.example.com/oauth/authorize?client_id=console.....
   The http status code is 503.
3. 
[root@localhost ~]# oc logs -f oauth-openshift-848695688f-nh9mk -n openshift-authentication
Command "openshift-osinserver" is deprecated, will be removed in 4.0
I0708 06:46:30.527505       1 clientca.go:92] [0] "/tmp/requestheader-client-ca-file540855750" client-ca certificate: "openshift-kube-apiserver-operator_aggregator-client-signer@1562313905" [] issuer="<self>" (2019-07-05 08:05:04 +0000 UTC to 2019-08-04 08:05:05 +0000 UTC (now=2019-07-08 06:46:30.527489853 +0000 UTC))
I0708 06:46:30.527790       1 clientca.go:92] [0] "/tmp/client-ca-file062348611" client-ca certificate: "admin-kubeconfig-signer" [] issuer="<self>" (2019-07-04 12:52:28 +0000 UTC to 2029-07-01 12:52:28 +0000 UTC (now=2019-07-08 06:46:30.527783678 +0000 UTC))
I0708 06:46:30.527816       1 clientca.go:92] [1] "/tmp/client-ca-file062348611" client-ca certificate: "kube-csr-signer_@1562316051" [] issuer="openshift-kube-controller-manager-operator_csr-signer-signer@1562313875" (2019-07-05 08:40:50 +0000 UTC to 2019-08-04 08:40:51 +0000 UTC (now=2019-07-08 06:46:30.527809682 +0000 UTC))
I0708 06:46:30.527823       1 clientca.go:92] [2] "/tmp/client-ca-file062348611" client-ca certificate: "openshift-kube-controller-manager-operator_csr-signer-signer@1562313875" [] issuer="<self>" (2019-07-05 08:04:34 +0000 UTC to 2019-09-03 08:04:35 +0000 UTC (now=2019-07-08 06:46:30.527818969 +0000 UTC))
I0708 06:46:30.527831       1 clientca.go:92] [3] "/tmp/client-ca-file062348611" client-ca certificate: "kube-apiserver-to-kubelet-signer" [] issuer="<self>" (2019-07-04 12:52:33 +0000 UTC to 2020-07-03 12:52:33 +0000 UTC (now=2019-07-08 06:46:30.52782651 +0000 UTC))
I0708 06:46:30.527838       1 clientca.go:92] [4] "/tmp/client-ca-file062348611" client-ca certificate: "kube-control-plane-signer" [] issuer="<self>" (2019-07-04 12:52:33 +0000 UTC to 2020-07-03 12:52:33 +0000 UTC (now=2019-07-08 06:46:30.527833826 +0000 UTC))
I0708 06:46:30.531942       1 secure_serving.go:66] Forcing use of http/1.1 only
I0708 06:46:30.532627       1 serving.go:195] [0] "/var/config/system/secrets/v4-0-config-system-serving-cert/tls.crt" serving certificate: "oauth-openshift.openshift-authentication.svc" [serving] validServingFor=[oauth-openshift.openshift-authentication.svc,oauth-openshift.openshift-authentication.svc.cluster.local] issuer="openshift-service-serving-signer@1562255540" (2019-07-04 16:24:58 +0000 UTC to 2021-07-03 16:24:59 +0000 UTC (now=2019-07-08 06:46:30.532617958 +0000 UTC))
I0708 06:46:30.532645       1 serving.go:195] [1] "/var/config/system/secrets/v4-0-config-system-serving-cert/tls.crt" serving certificate: "openshift-service-serving-signer@1562255540" [] issuer="<self>" (2019-07-04 15:52:20 +0000 UTC to 2020-07-03 15:52:21 +0000 UTC (now=2019-07-08 06:46:30.532639796 +0000 UTC))
I0708 06:46:30.532655       1 secure_serving.go:136] Serving securely on 0.0.0.0:6443
I0708 06:46:30.532673       1 clientca.go:58] Starting DynamicCA: /tmp/requestheader-client-ca-file540855750
I0708 06:46:30.532801       1 serving.go:77] Starting DynamicLoader
I0708 06:46:30.533483       1 clientca.go:58] Starting DynamicCA: /tmp/client-ca-file062348611
I0708 06:47:34.231301       1 log.go:172] http: TLS handshake error from 10.129.2.1:43884: EOF
I0708 06:52:10.302372       1 log.go:172] http: TLS handshake error from 10.128.2.1:40566: EOF
I0708 06:54:12.694135       1 log.go:172] http: TLS handshake error from 10.128.2.1:43482: EOF
I0708 07:01:19.690399       1 log.go:172] http: TLS handshake error from 10.129.2.1:59266: EOF
I0708 07:03:16.636261       1 log.go:172] http: TLS handshake error from 10.130.0.1:60278: EOF
I0708 07:03:37.149539       1 log.go:172] http: TLS handshake error from 10.129.2.1:33408: EOF
I0708 07:03:37.794161       1 log.go:172] http: TLS handshake error from 10.129.2.1:33426: EOF
Actual results:


Expected results:


Additional info:

Comment 1 Standa Laznicka 2019-07-10 13:48:53 UTC
This is probably happening because the OAuth server will always force HTTP 1.1 (as seen in the log - `I0708 06:46:30.531942       1 secure_serving.go:66] Forcing use of http/1.1 only`).

This had to be done because of the issues we encountered during the development of the authentication-operator for 4.1. You can read about them in https://bugzilla.redhat.com/show_bug.cgi?id=1686476#c16. The OAuth server as deployed in the cluster today fulfills all the requirements to be hitting the mentioned bug.

Comment 9 Michal Fojtik 2020-05-12 10:54:06 UTC
This bug hasn't had any activity in the last 30 days. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

As such, we're marking this bug as "LifecycleStale".

If you have further information on the current state of the bug, please update it, otherwise this bug will be automatically closed in 7 days. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

Comment 10 Stefan Schimanski 2020-05-12 12:00:05 UTC
There is no plan to fix this in 4.5.

Comment 11 Stefan Schimanski 2020-05-19 08:38:45 UTC
*** Bug 1826994 has been marked as a duplicate of this bug. ***

Comment 12 Stefan Schimanski 2020-05-20 08:08:42 UTC
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.

Comment 13 Andrew McDermott 2020-05-21 15:24:24 UTC
Setting "ROUTER_ENABLE_HTTP2=TRUE" was removed in 4.4.

And in 4.5 we are enabling HTTP/2 by default for re-encrypt and passthrough routes that use a custom certificate.

Comment 14 Miciah Dashiel Butler Masters 2020-05-21 15:55:22 UTC
The general goal of supporting HTTP/2 for OAuth is reasonable.  One way to achieve that goal would be to implement https://issues.redhat.com/browse/RFE-507 so that the cluster administrator could configure a custom host and certificate for OAuth.  If the OAuth route had a custom host and certificate, we could then enable HTTP/2 for that route.


Comment 15 Stefan Schimanski 2020-06-18 09:10:06 UTC
This is blocked by custom cert support, as comment #14 suggests.

Comment 16 Maru Newby 2020-07-10 21:53:26 UTC
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.

Comment 17 Maru Newby 2020-07-31 16:34:27 UTC
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.

Comment 18 Maru Newby 2020-08-22 01:44:29 UTC
This bug will be evaluated next sprint.

Comment 19 Michal Fojtik 2020-08-24 13:11:53 UTC
This bug hasn't had any activity in the last 30 days. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're marking this bug as "LifecycleStale" and decreasing the severity/priority. If you have further information on the current state of the bug, please update it, otherwise this bug can be closed in about 7 days. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

Comment 20 Michal Fojtik 2020-08-31 14:00:11 UTC
This bug hasn't had any activity 7 days after it was marked as LifecycleStale, so we are closing this bug as WONTFIX. If you consider this bug still valuable, please reopen it or create new bug.

Comment 21 Michal Fojtik 2020-08-31 14:59:59 UTC
The LifecycleStale keyword was removed because the bug got commented on recently.
The bug assignee was notified.