Description of problem: The general user cannot create the subscription on the Web but can do this in the terminal. Version-Release number of selected component (if applicable): quay.io/coreos/olm@sha256:44b445850b3e612c062424c3727bb85048ec8e71407b39985786d29aa20f5c79 quay.io/coreos/catalog@sha256:20886d49205aa8d8fd53f1c85fad6a501775226da25ef14f51258b7066e91064 image: registry.reg-aws.openshift.com:443/openshift3/ose-console:v3.11 imageID: docker-pullable://registry.reg-aws.openshift.com:443/openshift3/ose-console@sha256:2047bb4f3cbcef42550b1a6d29dc5d5ed99b6096fe92ede8bfd2f4e08d597824 How reproducible: always Steps to Reproduce: 1. Login the cluster as a general user in the terminal. [jzhang@localhost ~]$ oc login https://qe-jiazha-master-etcd-1.0906-c4y.qe.rhcloud.com:8443 The server uses a certificate signed by an unknown authority. You can bypass the certificate check, but any data you send to the server could be intercepted by others. Use insecure connections? (y/n): y Authentication required for https://qe-jiazha-master-etcd-1.0906-c4y.qe.rhcloud.com:8443 (openshift) Username: jiazha2 Password: Login successful. You don't have any projects. You can try to create a new project, by running oc new-project <projectname> 2. Create a project. [jzhang@localhost ~]$ oc new-project jian2 Now using project "jian2" on server "https://qe-jiazha-master-etcd-1.0906-c4y.qe.rhcloud.com:8443". You can add applications to this project with the 'new-app' command. For example, try: oc new-app centos/ruby-22-centos7~https://github.com/openshift/ruby-ex.git to build a new example application in Ruby. [jzhang@localhost ~]$ oc project Using project "jian2" on server "https://qe-jiazha-master-etcd-1.0906-c4y.qe.rhcloud.com:8443". 3. Create a subscription. The subscription creates success. [jzhang@localhost ~]$ oc create -f subscription.yaml subscription.operators.coreos.com "etcd-5snf9" created [jzhang@localhost ~]$ cat subscription.yaml apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: generateName: etcd- namespace: jian2 spec: source: ocs name: etcd startingCSV: etcdoperator.v0.9.2 channel: alpha [jzhang@localhost ~]$ oc get pods NAME READY STATUS RESTARTS AGE etcd-operator-7b49974f5b-j4z4m 3/3 Running 0 1m [jzhang@localhost ~]$ oc get rolebinding NAME ROLE USERS GROUPS SERVICE ACCOUNTS SUBJECTS admin /admin jiazha2 etcdoperator.v0.9.2-role-9kl9k-etcd-operator-rolebinding-shfx8 jian2/etcdoperator.v0.9.2-role-9kl9k etcd-operator etcdoperator.v0.9.2-role-nqs96-etcd-operator-rolebinding-g68m7 jian2/etcdoperator.v0.9.2-role-nqs96 etcd-operator system:deployers /system:deployer deployer system:image-builders /system:image-builder builder system:image-pullers /system:image-puller system:serviceaccounts:jian2 4, Login the cluster on the Web. 5, Login the "Cluster Console" Actual results: The general user cannot find the subscription option. So, they could not create the subscription on the Web. Expected results: The general users can create the subscription on the Web. Or the general users cannot create the subscription in the terminal. Additional info:
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.
https://github.com/openshift/console/pull/518
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.