Bug 1625996
| Summary: | [olm] The common user cannot get the catalogsource resources | ||
|---|---|---|---|
| Product: | OpenShift Container Platform | Reporter: | Jian Zhang <jiazha> |
| Component: | OLM | Assignee: | Evan Cordell <ecordell> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Jian Zhang <jiazha> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 3.11.0 | CC: | aos-bugs, chezhang, dyan, ecordell, jfan, jokerman, mmccomas, spadgett, xiaocwan, yapei, zitang |
| Target Milestone: | --- | ||
| Target Release: | 3.11.0 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Release Note | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-12-21 15:23:07 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: | |||
|
Description
Jian Zhang
2018-09-06 10:46:40 UTC
The RBAC rules to create subscriptions don't affect which console you see (the project console or the admin console). You shouldn't see subscriptions in the project console even if you technically could create them. Evan, Yes, I know, but I think we should grant the same permission to the general user whether in the terminal or on the Web. I was wondering if we can modify the RBAC roles to restrict this behavior of the general user in the terminal. In other words, who's the target users for the OLM component? All users? Or the cluster-admin users? We add the cluster role "aggregate-olm-edit" to the "admin"(here: https://github.com/openshift/openshift-ansible/blob/master/roles/olm/files/aggregated-edit.clusterrole.yaml), so the general users should get the related permissions on Web. Maybe this is a UI issue. Correct me if I'm wrong. As far as I'm aware, if a user has RBAC access to OLM types and OLM is installed, they will see the "Operators" UI in the console. We currently hide the entire Operators nav section in the UI if the user can't list ClusterServiceVersions. We probably need more granular checks for each nav item if we should be showing them. Evan & Samuel FYI, the common users can get the "Operators" plane on the Web now. But, got the below errors when clicking the "CatalogSource" field. Is it as expected? Or is it a new bug? @Evan catalogsources.operators.coreos.com is forbidden: User "jiazha" cannot list catalogsources.operators.coreos.com in the namespace "operator-lifecycle-manager": no RBAC policy matched In general, installing operators is a privileged action. If you create a user that has RBAC access to *.operators.coreos.com then you can view and install them. For example, a ClusterRoleBinding to the `edit` ClusterRole for your user will let you manage operator installation. Evan,
I tried the solution which you said above, but it didn't work.
Steps:
[root@share-wmenghaglb3116-mez-1 ~]# oc adm policy add-cluster-role-to-user aggregate-olm-edit jianzhangbjz
cluster role "aggregate-olm-edit" added: "jianzhangbjz"
[root@share-wmenghaglb3116-mez-1 ~]# oc adm policy who-can watch catalogsources
Namespace: operator-lifecycle-manager
Verb: watch
Resource: catalogsources.operators.coreos.com
Users: QiaolingTang
jianzhangbjz
But, I still got the same errors:
configmaps is forbidden: User "jianzhangbjz" cannot list configmaps in the namespace "default": no RBAC policy matched
As you know, the catalogsource is a namespaced resource which stored in the "operator-lifecycle-manager" project. But, the common user cannot access it even if they have got the "aggregate-olm-edit" permission. Is it a bug?
I think we should explain who is the target user for the OLM, the cluster admin? or the common user?
Per comment 8 and comment 9, console issue has been resolved, move to OLM component for further discussion/fix Change title to " The common user cannot get the catalogsource resources" for more clear. Waiting for Evan's response, change status to "ASSIGNED" first based on my understanding. The cluster admin is the target user for OLM, and the version shipping for 4.0 will be much clearer in the way permissions are handled. The cluster administrator decides which operators to enable for which namespaces, hands out access to the services to non-admins via RBAC. The above should work if you use: # oc adm policy add-cluster-role-to-user edit jianzhangbjz Evan,
> # oc adm policy add-cluster-role-to-user edit jianzhangbjz
yes, it works. But, I concern that this operation will give the common user the editing permission of all namespaces in the cluster. Anyway, this permission will be delivered by the cluster-admin user. That meets the permission management.
LGTM, verify it. And, I think we need to add this operation to the release doc. Correct me if I'm wrong.
Zhangjian, FYI, No need to grant cluster-role to user, just `oc policy add-role-to-user view xiaocwan -n operator-lifecycle-manager` is okay. Yes, thanks! You also need to grant the role "etcdoperator.v0.9.2-role-9rswg" to the user if you want to create the etcd-cluster. Otherwise, you will get the errors when create the cluster instance managing by the Operator, for example, etcdclusters.etcd.database.coreos.com is forbidden: User "jiazha" cannot list etcdclusters.etcd.database.coreos.com in the namespace "jian": no RBAC policy matched The following are the steps to grant permission to the common user for creating etcd-operator and etcd-cluster. 1, [root@qe-jiazhamaster-etcd-1 ~]# oc policy add-role-to-user view jiazha2 -n operator-lifecycle-manager Note that: different operator different role 2, [root@qe-jiazhamaster-etcd-1 ~]# oc policy add-role-to-user etcdoperator.v0.9.2-role-9rswg jiazha2 --role-namespace=jiazha Sorry, my mistake the correct error info above should be: prometheuses.monitoring.coreos.com is forbidden: User "jiazha2" cannot list prometheuses.monitoring.coreos.com in the namespace "jiazha": no RBAC policy matched Closing bugs that were verified and targeted for GA but for some reason were not picked up by errata. This bug fix should be present in current 3.11 release content. |