search

openshift / oauth-proxy

A reverse proxy that provides authentication with OpenShift via OAuth and Kubernetes service accounts
MIT License
263 stars 138 forks source link

Issue 107: Add option to pass authorization bearer to upstream #111

Closed InfoSec812 closed 4 years ago

InfoSec812 commented 5 years ago

Resolves #107

This adds a new option --pass-auth-bearer which causes the proxy to pass the Authorization: Bearer <TOKEN> header to upstreams.

openshift-ci-robot commented 5 years ago

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: InfoSec812 To fully approve this pull request, please assign additional approvers. We suggest the following additional approver: ericavonb

If they are not already assigned, you can assign the PR to them by writing /assign @ericavonb in a comment when ready.

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files: - **[OWNERS](https://github.com/openshift/oauth-proxy/blob/master/OWNERS)** Approvers can indicate their approval by writing `/approve` in a comment Approvers can cancel approval by writing `/approve cancel` in a comment
openshift-ci-robot commented 5 years ago

Hi @InfoSec812. Thanks for your PR.

I'm waiting for a openshift member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.
InfoSec812 commented 5 years ago

Interesting... The tests pass for me locally when running go test

enj commented 5 years ago

/hold

I do not believe this is a use case we want to support.

InfoSec812 commented 5 years ago

@enj I'd like to understand your reasoning... In my mind, something like this is the same argument as using Istio/Envoy to implement circuit breakers. Instead of having to write custom code to implement OAuth in applications it becomes a deployment detail and reduces cognitive load, developer overhead, and application complexity.

k-wall commented 5 years ago

@enj we too have a desire for this feature. I put a summary of our use-case in #107. Currently we need to deploy a HTTPD sidecar behind oauth-proxy to rewrite the headers of the API requests X-Forwarded-Access-Token => Authorization "Bearer...". This is ugly. If we had @InfoSec812's feature, this ugliness goes away.

mrogers950 commented 5 years ago

Does it have to be a conversion to an Authorization header or would it be enough to make it so that there is a way to change "X-Forwarded-Access-Token" to something else? Sorry, we do have some hesitation because our long term goal with this project is to rewrite it to a minimal OpenShift proxy that is stripped down to its core functionality that is suitable for the OpenShift components that consume it. We want to avoid adding a lot of customization if we can help it, in its current state there is already too many options. We did not intend for this project to be a swiss army knife proxy and want to trim it down.

InfoSec812 commented 5 years ago

@mrogers950 I would say that for me the order of preference would be:

  1. OpenShift API and K8s API to support X-Forwarded-Access-Token (Seems unlikely near-term)
  2. Allow a configurable header to pass the OAuth token
  3. Keep the change as submitted

If you like, I can resubmit modifying the functionality of the X-Forwarded-Access-Token

k-wall commented 5 years ago

@mrogers950 I would say that for me the order of preference would be:

  1. OpenShift API and K8s API to support X-Forwarded-Access-Token (Seems unlikely near-term)
  2. Allow a configurable header to pass the OAuth token
  3. Keep the change as submitted

If you like, I can resubmit modifying the functionality of the X-Forwarded-Access-Token

@mrogers950, we (EnMasse.io) too are using oauth-proxy to proxy the OpenShift API and K8s APIs. My preferences are the same as @InfoSec812.

mrogers950 commented 5 years ago

@InfoSec812 @k-wall I'd accept a solution like #2 (not sure how @enj feels about it). We should have the default header remain as X-Forwarded-Access-Token and let it change with an optional flag like --token-header-name or similar.

InfoSec812 commented 5 years ago

@mrogers950 Makes sense. Don't break the existing functionality, but allow overriding it when the user wants to. I will see if I can modify this PR or perhaps submit as a new PR.

InfoSec812 commented 5 years ago

Oh! Wait... That won't work... The "Authorization" header needs to be in the form of "Bearer \<TOKEN>" and not just the bare token. So, even if I did implement this as requested, OpenShift and K8s wouldn't accept it.

enj commented 5 years ago

/uncc

@stlaz @sttts @mfojtik

openshift-bot commented 4 years ago

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close. Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

openshift-bot commented 4 years ago

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten. Rotten issues close after an additional 30d of inactivity. Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten /remove-lifecycle stale