Bug 1849983 - When user grant role/admin to service account group,the service account cannt use cmd 'oc project' to switch to the target ns
Summary: When user grant role/admin to service account group,the service account cannt...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: oc
Version: 4.5
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: ---
: 4.6.0
Assignee: Standa Laznicka
QA Contact: scheng
URL:
Whiteboard:
Depends On:
Blocks: 1850452
TreeView+ depends on / blocked
 
Reported: 2020-06-23 10:50 UTC by scheng
Modified: 2020-10-27 16:09 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: `oc project` started requiring the privileges of a self-provisioner role to switch projects. Consequence: Switching projects wouldn't be possible when users did not have the self-provisioner privileges. Fix: Remove the privileges requirement. Result: Anyone with access to a project should be capable of switching to it by using `oc project`.
Clone Of:
Environment:
Last Closed: 2020-10-27 16:08:40 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github openshift oc pull 476 0 None closed Bug 1849983: allow switching project even to users outside self-provisioner role (revert) 2021-02-21 12:55:42 UTC
Red Hat Product Errata RHBA-2020:4196 0 None None None 2020-10-27 16:09:01 UTC

Description scheng 2020-06-23 10:50:07 UTC
Description of problem:

When user grant role/admin to service account group,the service account cannt use cmd oc project to switch to the target ns

Version-Release number of selected component (if applicable):

# oc get clusterversion
NAME      VERSION                             AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.5.0-0.nightly-2020-06-22-193506   True        False         10m     Cluster version is 4.5.0-0.nightly-2020-06-22-193506


How reproducible: always

Steps to Reproduce:

1. # oc login -u xxx -p xxx
2. # oc new-project test-1
3. # oc new-project test-2
4. # oc policy add-role-to-group admin system:serviceaccounts:test-1
5. # oc sa get-token 'default' -n test-1
6. # oc login --token=eyJhbGc...Zw
7. # oc project test-2
Error from server (Forbidden): You may not request a new project via this API.
[root@preserve-auth-0211 ~]# oc get clusterversion
Error from server (Forbidden): clusterversions.config.openshift.io is forbidden: User "system:serviceaccount:test-1:default" cannot list resource "clusterversions" in API group "config.openshift.io" at the cluster scope


Actual results:

The service account cannt switch to the target ns,but the service account can get or create some resource under the target ns through '-n'.

Expected results:

The service account can switch to the target via 'oc project'

Additional info:

The user group like system:authenticated can switch to the target ns successfuly!

Comment 1 Standa Laznicka 2020-06-23 12:28:07 UTC
Groups don't get created per-NS.

4. # oc policy add-role-to-group admin system:serviceaccounts:test-1

should be

oc adm policy add-role-to-group admin system:serviceaccounts -n test-1

But even then, serviceaccounts are by default not allowed to access projectrequest API, so this would still fail.

Unless your steps are based on a documentation that you found somewhere, I would close this as NOTABUG.

Comment 2 scheng 2020-06-23 12:47:31 UTC
Why need 'oc adm'? 

And `oc adm policy add-role-to-group admin system:serviceaccounts -n test-1` only create a new rolebinding under ns/test-1,the test scenario is
granting the admin permission of ns/test-2 to the service account group under ns/test-1.

QE have many automation test scenario that using SA to switch to the target NS,this has always been successful, but it has failed recently!

Feel free to close this.

Comment 3 Standa Laznicka 2020-06-23 13:04:49 UTC
Apparently I am wrong, there do seem to be NS-based groups, I should do fact-checking before posting. I guess that suggests this could be a regression?

Comment 8 Standa Laznicka 2020-06-24 07:28:40 UTC
Good job finding that PR, Scheng! I'm going to move this to `oc`.

Comment 9 scheng 2020-06-24 07:45:39 UTC
I am not sure if you move this to `oc` is right.

Comparison with normal users,the SA lack the clusterrole of self-provisioner which contains permission to create projectrequests.

If you think the SA should not have that permission, you could close this.

Comment 10 Standa Laznicka 2020-06-24 07:53:13 UTC
The lack of self-provisioner permission is intentional, SA should mostly just stay contained within its own namespace. I moved the BZ to `oc` because a potential use-case got broken, however untraditional it may be. It's up to them to see whether this was done intentionally, and whether they would like to fix it.

Comment 11 scheng 2020-06-24 07:59:50 UTC
Good comments,slaznick! let's wait for other related Dev'comments.

Thanks!

Comment 12 Standa Laznicka 2020-06-24 08:06:00 UTC
I just realized, this is no longer about service-accounts only.

There is a valid use-case where cluster amininistrators remove self-provisioner clusterrole from system:authenticated:oauth so that they remove the ability from the users to create projects, instead the administrators create projects themselves and assign users to them. This workflow appears to be broken now as well.

This is a regression.

Comment 17 errata-xmlrpc 2020-10-27 16:08:40 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (OpenShift Container Platform 4.6 GA Images), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:4196


Note You need to log in before you can comment on or make changes to this bug.