Bug 1849983
| Summary: | When user grant role/admin to service account group,the service account cannt use cmd 'oc project' to switch to the target ns | ||
|---|---|---|---|
| Product: | OpenShift Container Platform | Reporter: | scheng |
| Component: | oc | Assignee: | Standa Laznicka <slaznick> |
| Status: | CLOSED ERRATA | QA Contact: | scheng |
| Severity: | urgent | Docs Contact: | |
| Priority: | urgent | ||
| Version: | 4.5 | CC: | aos-bugs, jokerman, maszulik, mfojtik, slaznick, wking, wlewis |
| Target Milestone: | --- | Keywords: | Regression |
| Target Release: | 4.6.0 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| 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`.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-10-27 16:08:40 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1850452 | ||
|
Description
scheng
2020-06-23 10:50: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. 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 |