Bug 2059186

Summary: ConsolePlugin proxy always passes Authorization header even if `authorize` property is omitted or false
Product: OpenShift Container Platform Reporter: OpenShift BugZilla Robot <openshift-bugzilla-robot>
Component: Management ConsoleAssignee: Samuel Padgett <spadgett>
Status: CLOSED ERRATA QA Contact: Yadan Pei <yapei>
Severity: high Docs Contact:
Priority: unspecified    
Version: 4.10CC: aos-bugs, spadgett
Target Milestone: ---   
Target Release: 4.10.z   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-04-12 08:10:44 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On: 2058424    
Bug Blocks:    

Description OpenShift BugZilla Robot 2022-02-28 12:56:38 UTC
+++ This bug was initially created as a clone of Bug #2058424 +++

Description of problem:

As described in the Dynamic Plugin SDK enhancement, a plugin can set up a proxy to another service in the cluster via a `proxy` property on the ConsolePlugin resource. See "In case the plugin needs to communicate with some in-cluster service" here: https://github.com/openshift/enhancements/blob/master/enhancements/console/dynamic-plugins.md#delivering-plugins

This proxy configuration has an optional property called `authorize` which this document describes as defaulting to false. This is reflected on the ConsolePlugin CRD:
> By default the access token is not part of the proxied request.

Version-Release number of selected component (if applicable): 4.10-rc1

If possible, we'd like to target 4.10 for this plugin's GA release.

How reproducible: 100%

Steps to Reproduce:
1. Set up a Dynamic Plugin with a service proxy configured in the ConsolePlugin spec, with the authorize flag omitted or false
2. Make a request to the proxied URL that does not include an Authorization header, or includes one with a custom bearer token.
3. Look in the logs of the service being proxied and see that an Authorization header was indeed passed.
4. Compare the bearer token in that header to the one observable in the dev tools of the Console UI being passed in other API requests.

Actual results:

I have tried excluding that flag and setting it to false, and in both cases the access token indeed ends up part of the proxied request. If I pass my own bearer token with the request, it gets replaced with the built-in one for the current user.

Expected results:

If the authorize flag is omitted or false, the Authorization header should be left alone (excluded if not present in the request, or left as-is if present in the request). Headers of the original request should be retained as-is in the request received by the proxied service.

Additional info:

Issue observed in https://github.com/konveyor/crane-ui-plugin and reported there as https://issues.redhat.com/browse/MIG-1093

--- Additional comment from mturley@redhat.com on 2022-02-24 21:40:47 UTC ---

See discussion on Slack here: https://coreos.slack.com/archives/C011BL0FEKZ/p1645734204061589


--- Additional comment from mturley@redhat.com on 2022-02-24 21:42:09 UTC ---

@spadgett@redhat.com seems to have found the root cause:

> I suspect this line always adds the header: https://github.com/openshift/console/blob/master/pkg/server/server.go#L541
> Potential fix, although I haven’t fully tested yet: https://github.com/openshift/console/pull/11102

Comment 5 errata-xmlrpc 2022-04-12 08:10:44 UTC
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.10.9 bug fix update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.