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.

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

[Story] Manage our own OAuthClient #579

Open
Tracked by #1489
ebaron opened this issue May 5, 2023 · 3 comments
Open
Tracked by #1489

[Story] Manage our own OAuthClient #579

ebaron opened this issue May 5, 2023 · 3 comments
Labels

Comments

@ebaron
Copy link
Member

ebaron commented May 5, 2023

In order to allow Cryostat to get a scoped token across additional namespaces, we can't use a Service Account as an OAuth client.

I've been able to track down why the OAuth grant is failing for multiple namespaces.

Here is the OAuthClient derived from the Service Account in namespace c:

metadata:
 name: system:serviceaccount:c:clustercryostat-sample
additionalSecrets:
 - <service_account_token>
redirectURIs:
 - https://clustercryostat-sample-c.apps.example.com
grantMethod: prompt
scopeRestrictions:
 - literals:
     - user:info
     - user:check-access
     - user:list-scoped-projects
     - user:list-projects
 - clusterRole:
     roleNames:
       - '*'
     namespaces:
       - c
     allowEscalation: true

This is the error from ValidateScopeRestrictions when trying to create a scoped token for namespaces a, b, and c:

error: '[role:cryostat-operator-oauth-client:a not found in [user:info user:check-access user:list-scoped-projects user:list-projects], role:cryostat-operator-oauth-client:a does not use an approved namespace, role:cryostat-operator-oauth-client:b not found in [user:info user:check-access user:list-scoped-projects user:list-projects], role:cryostat-operator-oauth-client:b does not use an approved namespace]'
errorCauses:
  - error: '[role:cryostat-operator-oauth-client:a not found in [user:info user:check-access user:list-scoped-projects user:list-projects], role:cryostat-operator-oauth-client:a does not use an approved namespace]'
    errorCauses:
      - error: role:cryostat-operator-oauth-client:a not found in [user:info user:check-access user:list-scoped-projects user:list-projects]
      - error: role:cryostat-operator-oauth-client:a does not use an approved namespace
  - error: '[role:cryostat-operator-oauth-client:b not found in [user:info user:check-access user:list-scoped-projects user:list-projects], role:cryostat-operator-oauth-client:b does not use an approved namespace]'
    errorCauses:
      - error: role:cryostat-operator-oauth-client:b not found in [user:info user:check-access user:list-scoped-projects user:list-projects]
      - error: role:cryostat-operator-oauth-client:b does not use an approved namespace

Looking at the OAuthClient, it has a scope restriction requiring the role scopes be in c. The docs indicate this is by design:

You can use a service account as a constrained form of OAuth client. Service accounts can request only a subset of scopes that allow access to some basic user information and role-based power inside of the service account’s own namespace

It seems like in order to get a scoped token to work for multiple namespaces, we can't use the service account as an OAuth client. We would have to manage our own OAuthClient(s): https://docs.openshift.com/container-platform/4.12/authentication/configuring-oauth-clients.html#oauth-register-additional-client_configuring-oauth-clients.

Originally posted by @ebaron in https://github.com/cryostatio/cryostat/issues/1188#issuecomment-1483219220

@andrewazores
Copy link
Member

Needs to be revisited for 3.0 with the new authproxy architecture.

@andrewazores andrewazores moved this to Stretch Goals in 3.0.0 release Jun 7, 2024
@andrewazores
Copy link
Member

Does this still apply now that we deploy the openshift-oauth-proxy instead?

@ebaron
Copy link
Member Author

ebaron commented Jun 7, 2024

The OAuth proxy lets us use a custom OAuthClient, but I'm not sure how useful this would be since it limits the permission check to one in the openshift-delegate-urls option. I'm not sure if we could express something like checking for pod/exec in namespaces A and B.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
No open projects
Status: Stretch Goals
Development

No branches or pull requests

2 participants