search

openshift / oauth-proxy

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

Need user authorization token for proper RBAC settings on custom backend APIs #221

Closed ivandov closed 2 years ago

ivandov commented 3 years ago

I believe this question is similar to the problems referenced in #107 and #111.

I have a frontend/backend application that is interfacing directly with OCP CustomResources that we manage through our application. We have backend APIs that manage these CRs based on user actions.

I want to secure these APIs using the oauth-proxy and only allowing users with certain RBACs to be able to perform appropriate CRUD actions based on their RBAC settings for our various CRs. I also want to restrict portions of our frontend based on a user's authorizations (i.e. if they're not what we consider our "app admin persona", then they shouldn't be able to use certain UIs).

Since we have a slew of APIs, I would need to craft some pretty dynamic SubjectAccessReview requests in order to properly secure my API. For example, I want to have a frontend UI that can only be displayed if a user has RBAC permissions to get on a CustomInstance (example CR kind) with resourceName: foo.

As far as I can tell, the SAR that I'd have to write in the oauth-proxy config wouldn't be able to easily set the dynamic values for the resourceName for various users and various APIs, and therefore I wouldn't be able to craft unique SARs for individual users.

Wouldn't I need the authenticated user's Bearer Token on our backend? Then I'd be able to call the apis/authorization.openshift.io/v1/subjectaccessreviews API directly with the user's token and identify if they have the proper permissions needed for our a specific API.

Am I missing something? Is there some other way that this can be done? Only other solution I'm considering is making our backend act as a full oauth client, but, that seems like redundant implementations when the oauth-proxy already handles all of this for me.

ivandov commented 2 years ago

Any update here? Or suggestion on a different direction to take?

tuananh commented 2 years ago

I'm interested in this as well

openshift-bot commented 2 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 2 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

openshift-bot commented 2 years ago

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen. Mark the issue as fresh by commenting /remove-lifecycle rotten. Exclude this issue from closing again by commenting /lifecycle frozen.

/close

openshift-ci[bot] commented 2 years ago

@openshift-bot: Closing this issue.

In response to [this](https://github.com/openshift/oauth-proxy/issues/221#issuecomment-1073498661): >Rotten issues close after 30d of inactivity. > >Reopen the issue by commenting `/reopen`. >Mark the issue as fresh by commenting `/remove-lifecycle rotten`. >Exclude this issue from closing again by commenting `/lifecycle frozen`. > >/close 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.