Reading current user role about openshift-restclient-java HOT 14 CLOSED

• Did you instantiate the client as describe here: https://github.com/openshift/openshift-restclient-java#usage
• Do you have the proper permissions to read the default namespace?
• Can you define exactly what information you require and detail how you tried to retrieve it?

Note this client is not a replacement for 'oc' as 'oc' has ALOT of functionality that is baked in that has not been replicated in the java client. Given what you are trying to do, I'm not certain listing policy bindings will provide the desired outcome.

from openshift-restclient-java.

Thank you, answering your questions:

• Yes, have instatiate the client (using token) properly. I can use this client to list the project using the following code:
  client.list(ResourceKind.PROJECT);
• Yes, I'm using the same client to put projects, etc. using webconsole without any problems.
• I try to read client's role, for e.g. I added a role (edit) to this user:
  oadm policy add-role-to-user edit <user>
  After that I would like to read which role does the user belong to. Using oc I could read it (somewhere in
  the returned list) with the following command:
  oc describe policyBindings : default
  Now I try to get the user's role with restclient. If I'm using the following codes: client.list(ResourceKind.ROLE);, client.list(ResourceKind.POLICY); or client.list(ResourceKind.PROJECT_BINDING);, they all return the same exception as I mentioned before.
  My question: how could I read the user's role, in this case role: edit, using restclient? thank you in advance

from openshift-restclient-java.

I'm investigating but can you clarify how you retrieve policy bindings since the given syntax is not valid. I assume you are trying to retrieve policy bindings from the default namespace? Which would be:

oc describe policybindings -n default

from openshift-restclient-java.

It's a valid syntax (oc describe policyBindings :default ) :
https://docs.openshift.com/container-platform/3.3/admin_guide/manage_authorization_policy.html#viewing-local-policy
Have tested it. Thank you.

from openshift-restclient-java.

Added PR to verify. While testing:

• Log in as a developer with no cluster admin privileges, I get forbidden errors trying to read the default namespace.

com.openshift.restclient.authorization.ResourceForbiddenException: User "developer" cannot list roles in project "default" User "developer" cannot list roles in project "default"
	at com.openshift.internal.restclient.okhttp.ResponseCodeInterceptor.createOpenShiftException(ResponseCodeInterceptor.java:106)
	at com.openshift.internal.restclient.okhttp.ResponseCodeInterceptor.intercept(ResponseCodeInterceptor.java:65)
	at okhttp3.RealCall$ApplicationInterceptorChain.proceed(RealCall.java:190)
	at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.java:163)
	at okhttp3.RealCall.execute(RealCall.java:57)
	at com.openshift.internal.restclient.DefaultClient.execute(DefaultClient.java:217)
	at com.openshift.internal.restclient.DefaultClient.execute(DefaultClient.java:194)
	at com.openshift.internal.restclient.DefaultClient.execute(DefaultClient.java:183)
	at com.openshift.internal.restclient.DefaultClient.get(DefaultClient.java:286)
	at com.openshift.internal.restclient.DefaultClient.list(DefaultClient.java:126)
	at com.openshift.internal.restclient.DefaultClient.list(DefaultClient.java:120)
	at 

• Log in as a cluster-admin, and specifying the namespace: test passes without error.
• Log in as a cluster-admin and using the method signature where you do not specify a namespace:

com.openshift.restclient.OpenShiftException: The api endpoint for kind 'Role' requires a namespace
	at com.openshift.internal.restclient.URLBuilder.buildWithNamespaceInPath(URLBuilder.java:152)
	at com.openshift.internal.restclient.URLBuilder.build(URLBuilder.java:132)
	at com.openshift.internal.restclient.DefaultClient.execute(DefaultClient.java:210)
	at com.openshift.internal.restclient.DefaultClient.execute(DefaultClient.java:194)
	at com.openshift.internal.restclient.DefaultClient.execute(DefaultClient.java:183)
	at com.openshift.internal.restclient.DefaultClient.get(DefaultClient.java:286)
	at com.openshift.internal.restclient.DefaultClient.list(DefaultClient.java:126)
	at com.openshift.internal.restclient.DefaultClient.list(DefaultClient.java:120)
	at com.openshift.internal.restclient.DefaultClient.list(DefaultClient.java:115)

Maybe your token is invalid or expired. You should login as a cluster-admin and then provide the value provided by oc whoami -t. If I am logged in like oc login -u system:admin the previous command does not provide me a token: error: no token is currently in use for this session

Additionally, you might verify the user can do what you ask via oc policy who-can list policy -n default

from openshift-restclient-java.

@dermitdemwolftanzt ahh... i see. the original syntax you provided added a space between the kind and policy name which is why i did not recognize the command you provided

from openshift-restclient-java.

I'm quite sure that the token I'm using not expired/invalid, as you see you could reproduce this as well. As I said, the user is not cluster-admin/cluster-reader on purpose. So back to my initial question, is that any way to find out which role does the current, non priviledge user has, using restclient, without using (other) priviledge user (cluster admin/cluster reader) ?

from openshift-restclient-java.

The only way to accomplish that now might be to bump up the log level on the oc client via --loglevel=8 and see what REST calls are being made when doing 'oc who-can' and to replicate it in a capability. You might also be able to make similiar calls to what we are doing and provide the namespace for which you are interested. This should provide you with some information. This limitation, however, is not a restriction of this client; you are making calls in two different contexts (admin vs non-admin) so either way would provide you a forbidden error.

from openshift-restclient-java.

Hi, I've been hitting a similar error with

val request = client.get(ResourceKind.USER, null)

and was able to debug it. When authenticated with the same token, oc get users will contact GET https://127.0.0.1:8443/apis/user.openshift.io/v1/users?limit=500.

However, the openshift-restclient-java library will elect to call the oapi/v1/users endpoint instead.
From what I gather from the release notes of v3.7, the situation for users is likely similar to that of Roles and RoleBindings which where moved from /oapi/v1/roles to official /apis/rbac.authorization.k8s.io/v1beta1/roles

In 3.7, the RBAC objects become the source of truth. The OpenShift authorization policy objects no longer exist as real objects; the APIs are proxied to the RBAC resources.

Since openshift-restclient-java calls GET via the legacy oapi, the token needs the necessary permissions on this legacy API. For PUTs etc. the situation is different, i.e. the DefaultClient will infer the correct api and version from the payload (DefaultClient.java:243)

        final URL endpoint = new URLBuilder(this.baseUrl, typeMapper)
                .apiVersion(getApiVersion(payload))```

I think this is somewhat unfortunate. It would be great if there was an option to specify the apiVersion when doing a GET/LIST/WATCH request explicitly

from openshift-restclient-java.

@adietish Openshift is only required to support N-2. Given 3.10 is out we should consider migrating the oapi types to their new endpoints. It may resolve the issue here.

from openshift-restclient-java.

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

from openshift-restclient-java.

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

from openshift-restclient-java.

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

from openshift-restclient-java.

@openshift-bot: Closing this issue.

from openshift-restclient-java.