Fallback to OpenShift user API if no role granted

[zregvart]

Using delegating authentication and authorization requires a cluster role system:auth-delegator to be assigned to the service account the oauth_proxy is running under. This might be difficult to add if the cluster is not under control of the user deploying oauth_proxy.

This adds a fallback to use OpenShift user API for authentication and ignore authorization entirely.

[enj]

/hold

We can add a health check that fails to start the proxy if it is misconfigured (I thought we had something like this already). But we should not ignore the configuration in an attempt to get something that "works" but is not what the user requested.

[enj]

/assign @mrogers950

[simo5]

I feel this should be NACKed.
Emit an error and fail, let the user provide the correct config.

[zregvart]

The use case I'm trying to do is when the user is installing from a template, with rights only to the namespace the solution is being installed to.
The authentication/authorization is only used when it's delegated to OpenShift (i.e. with --openshift-delegate-urls). My complete use case is using --openshift-delegate-urls with --pass-user-bearer-token to access API service that outsources authentication to oauth-proxy. Not sure how to make this happen otherwise.

[rhuss]

@simo5 @enj so the requirement is for using delegating authentication and authorization requires cluster-admin role and can not used by a normal e.g. on OpenShift Online where you obviously don't have this role. Is this correct ? Isn't that a bit too restrictive then as most users don't have cluster-admin on their clusters.

What do you suggest as solution to @zregvart use case ? (actually this is a blocker for our project, Red Hat Fuse iPaaS)

thanks ...

[enj]

When set up by an unprivileged user, oauth proxy runs in an untrusted mode (openshift-sar) where it uses its SA to do an OAuth flow with the user. From this flow it obtains a limited scoped token to validate the user's access. This information gets stored in a cookie session for subsequent use. The important thing to note here is that the proxy never sees the user's full scoped token. This is required because anyone can set up this proxy, and we do not want users to get in the habit of sending off their tokens to random places. The SA as OAuth client flow in OpenShift was specifically built to make this scenario safe (Jenkins was the first use case). You can use pass-access-token to send the scoped token to the upstream service.

When openshift-delegate-urls is used, the proxy sees all tokens and uses the standard delegated authorization code used by trusted system components such as nodes. Any entity in such a configuration is dangerous because it sees all tokens, and thus could decide to record and abuse them. This is not a valid configuration for an untrusted proxy set up by an unprivileged user.

Note that cluster admin is not specifically required for the delegated auth configuration. A cluster role binding to system:auth-delegator is enough.

[zregvart]

@enj thank you for looking into this and for the providing additional details.

Let me explain our use case in more detail, as far as I can understand system:auth-delegator cannot be assigned to service accounts by the regular user, that is to say the user assigning the system:auth-delegator role to service account running oauth proxy needs to be a cluster admin. And that would mean that the user provisioning oauth proxy using a template needs to have cluster admin privileges.

When provisioning using templates to OpenShift Online and within this process we can't assign the system:auth-delegator role as we don't have cluster admin privileges.

We're delegating all security, which in our case boils down to just authentication and simplest authorization (if user can access the project) to oauth proxy. For browser use case this is not an issue as the cookie based flow you described is well suited. We are trying to find a way to make this work with non-browser (direct API) use using delegate auth.

If there is another way of achieving that we'd be happy to adopt it.

It seems to me that using subjectaccessreviews API and the user API for authentication accomplishes the same goal: for a given OAuth token return OK or error depending on the validity of the token. And on this assumption the pull request was based.

[simo5]

What you do boils down to make it easy for untrusted users to steal other users credentials, don't do that.

[zregvart]

What you do boils down to make it easy for untrusted users to steal other users credentials, don't do that.

We definitely don't want to endanger our users so if we're doing that I would like to understand how, can you elaborate a bit on this? Our use case is that oauth proxy is in front of our application, not in front of any application.

[enj]

And that would mean that the user provisioning oauth proxy using a template needs to have cluster admin privileges.

To be specific, you need to be able to create cluster role bindings and already have the powers of system:auth-delegator to be able to assign it someone else. Of course normal users do not have this power.

We are trying to find a way to make this work with non-browser (direct API) use using delegate auth.

You will need to go through the OAuth flow just like a browser would (i.e. client side HTML parsing and cookie management). The cookie would be used as the form of auth instead of a bearer token.

It seems to me that using subjectaccessreviews API and the user API for authentication accomplishes the same goal: for a given OAuth token return OK or error depending on the validity of the token.

It may be sufficient for your business and technical requirements. However, it violates the core security requirement for OAuth proxy that untrusted users and SAs must not see other user's tokens. As such we cannot support this use case.

Our use case is that oauth proxy is in front of our application, not in front of any application.

Any user can set up oauth proxy so there is no difference between the two scenarios.

---

In the future we have plans to allow users to easily create scoped tokens. We may be able to leverage that to make an untrusted token based flow (without OAuth) safe.

Closing per above.

[zregvart]

Thank you for your consideration, though I don't agree with the stated I see your point of view. We'll need to find some other way of accomplishing this.