[Task] Replace TokenReview with User self-query

[ebaron]

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 https://github.com/cryostatio/cryostat/issues/717#issuecomment-985773204

[andrewazores]

@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

[ebaron]

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.