Bug 2059186 - ConsolePlugin proxy always passes Authorization header even if `authorize` property is omitted or false
Summary: ConsolePlugin proxy always passes Authorization header even if `authorize` pr...
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Management Console
Version: 4.10
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: 4.10.z
Assignee: Samuel Padgett
QA Contact: Yadan Pei
Depends On: 2058424
TreeView+ depends on / blocked
Reported: 2022-02-28 12:56 UTC by OpenShift BugZilla Robot
Modified: 2022-04-12 08:11 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2022-04-12 08:10:44 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Github openshift console pull 11108 0 None Waiting on Red Hat Unable to get usable subscription data from Subscription Watch 2022-05-19 01:27:08 UTC
Red Hat Product Errata RHBA-2022:1241 0 None None None 2022-04-12 08:11:01 UTC

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 on 2022-02-24 21:40:47 UTC ---

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


--- Additional comment from mturley on 2022-02-24 21:42:09 UTC ---

@spadgett 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.


Note You need to log in before you can comment on or make changes to this bug.