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!
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.
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.
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?
Good job finding that PR, Scheng! I'm going to move this to `oc`.
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.
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.
Good comments,slaznick! let's wait for other related Dev'comments. Thanks!
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.
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