Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[Task] Replace TokenReview with User self-query #782

Open
ebaron opened this issue Dec 9, 2021 · 2 comments · May be fixed by #999
Open

[Task] Replace TokenReview with User self-query #782

ebaron opened this issue Dec 9, 2021 · 2 comments · May be fixed by #999
Assignees
@andrewazores
Labels
feat New feature or request

Comments

@ebaron
Copy link
Member

ebaron commented Dec 9, 2021

Interestingly user:info grants access to user.openshift.io/v1/users/~ which returns information on the user: https://docs.openshift.com/container-platform/4.9/rest_api/user_and_group_apis/user-user-openshift-io-v1.html. We could likely replace the TokenReview with this. This would cover all the permissions in https://github.com/cryostatio/cryostat-operator/blob/e524857960ffdfe44eaa360e9fd215d14b968953/config/rbac/cryostat_role.yaml, which would mean the operator doesn't need to create a ClusterRoleBinding for each Cryostat deployment. The ClusterRole could then just be used for the purpose of the role scope.

Originally posted by @ebaron in #717 (comment)
@ebaron ebaron added the feat New feature or request label Dec 9, 2021
@andrewazores andrewazores changed the title Replace TokenReview with User self-query [Task] Replace TokenReview with User self-query May 17, 2022
@andrewazores andrewazores self-assigned this Jun 13, 2022
@andrewazores
Copy link
Member

@ebaron the OpenShiftAuthManager implementation has user-scoped OpenShiftClient instances, where each one of those clients is instantiated using a user-supplied OAuth token (via the API Authorization headers and bearer tokens), plus one client using the service account's OAuth token. The TokenReview uses the service account client and validates that the user-supplied token does belong to an OAuth user - this is used for permissions checks that don't actually need any specific resource access (authorization), only that the token belongs to a real user (authentication).

If I'm remembering/understanding the context for this issue correctly, is the idea to use the user.openshift.io/v1/users/~ endpoint to perform a query with the user-token-scoped client instance, and pass the authentication check if the client is able to perform the query?

  1. Receive API request
  2. Extract OAuth token from HTTP Authorization header
  3. Construct OpenShiftClient instance using that token, or used a cached client instance if available
  4. Attempt to perform a user.openshift.io/v1/users/~ query
  5. If last step succeeds then the provided OAuth token belonged to a user with user:info permission, so authentication check passes. If the provided OAuth token does not belong to any user, or belongs to a user without user:info, then the query will fail and so we fail the application authentication check

@andrewazores andrewazores linked a pull request Jun 15, 2022 that will close this issue
Draft
@ebaron
Copy link
Member Author

ebaron commented Jun 15, 2022

That sounds about right, other than we need to request the user:info scope. I think all users by default are able to query users/~, but I'm not sure if this behaviour can be changed.

@tthvo tthvo mentioned this issue Aug 19, 2022
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@andrewazores andrewazores

Labels
feat New feature or request
Projects
No open projects
2.2.0 Release
Status: In Progress
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

feat(openshift): replace TokenReview with User self-query andrewazores/cryostat
2 participants
@andrewazores @ebaron