@Evan,

I think the project owner should NOT operate these resources(sub/csv/InstallPlan). And, the project owner can only use the services provided by the Operator in the "Developer Catalog" section. What do you think?

https://github.com/operator-framework/operator-lifecycle-manager/pull/812

@Evan,

One question, I'm not sure why we grant full control permission of the subscription subject to the common user.
This will lead to two problems:
1, On the Web console, the common user cannot do any operations to the Subscriptions object.
They can only use two sections: "Developer Catalog", "Installed Operators", there is no section for them to use the "Subscription" object.
That's means, they cannot delete the Subscription object on the Web console.

2, In the back end, the common user can create the subscription, that means they can install the operator in their namespace.
But, as the design, the operators should be installed by the cluster-admin user, not the common user.

In my opinion, grant the `view` permission is enough for the common user, management the operators is the cluster-admin users' responsibility.
The common user only needs to use the services provided by the operators. Correct me if I'm wrong.

Hi Jian,

I think you're right that in general we only want cluster-admins to have full control. But one of the things that cluster-admins can do is create catalogs of operators for other users to consume. In that case, I think it makes sense to have an access level that allows subscription to an operator (if it has been explicitly been made available via a catalog). This is high privileged but not cluster-admin level (users can't create new operators or escalate permissions), so it seems sensible to apply it to the `admin` role.

Users bound to "view" of course only have a read-only view of OLM resources, and can be bound to the roles for interacting with operator-provided CRs.

Hi Evan,

> This is high privileged but not cluster-admin level (users can't create new operators or escalate permissions), so it seems sensible to apply it to the `admin` role.

Thanks! I see, but the common users still cannot do the subscription operation on the Web console even if they have the `admin` role, is it as expected?
They can only do these in the backend.

Hi Jian,

I think you should be able to use the console, if you can't that should be a bug. I just tested it out and it looks like there are a couple of issues:

1. We weren't granting view access to OperatorGroups in the namespace, which the console uses to indicate which operators can be installed. Fixed this here: https://github.com/operator-framework/operator-lifecycle-manager/pull/833
2. The OLM UI is attempting to list namespaces, which namespace admins don't have permission to do. I'm not sure why it's currently trying to do that but will follow up with the console team.

The marketplace UI requires cluster-admin, though, because the marketplace actually creates new catalogs with new content from the internet.

Pull has merged.

Verify failed:

- The common users still cannot do the subscription operation on the Web console even if they have the `admin` role. On command line it's possible to manipulate without any issues.

oc login -u pm1

oc new-project testaccesspermission

oc get rolebindings -o yaml | grep pm1 -B 5     
    kind: ClusterRole
    name: admin
  subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: User
    name: pm1


cat subscriptionMongodb.yaml
```  
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  creationTimestamp: '2019-05-03T17:03:19Z'
  generation: 1
  labels:
    csc-owner-name: installed-certified-testaccesspermission
    csc-owner-namespace: openshift-marketplace
  name: mongodb-enterprisei1
  namespace: testaccesspermission
spec:
  channel: preview
  installPlanApproval: Automatic
  name: mongodb-enterprise
  source: installed-certified-testaccesspermission
  sourceNamespace: testaccesspermission
  startingCSV: mongodboperator.v0.9.0
```

oc create -f subscriptionMongodb.yaml                      
subscription.operators.coreos.com/mongodb-enterprisei1 created

oc get subs      
mongodb-enterprisei1   mongodb-enterprise   installed-certified-testaccesspermission   preview

oc delete subs mongodb-enterprisei1                                                         
subscription.operators.coreos.com "mongodb-enterprisei1" deleted


Cluster Version:

oc get clusterversion                                             
NAME      VERSION                             AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.1.0-0.nightly-2019-05-02-082538   True        False         123m    Cluster version is 4.1.0-0.nightly-2019-05-02-082538

OLM version:
          "io.openshift.build.commit.id": "bfc2f944d9d7007d445ed64242207bf7ca933f67",
          "io.openshift.build.commit.ref": "",
          "io.openshift.build.source-location": "https://github.com/operator-framework/operator-lifecycle-manager"

Console version:
          "io.openshift.build.commit.id": "fa1c7e8ef1a0745100bb7aa2b8912043a974f0f3",
          "io.openshift.build.commit.ref": "",
          "io.openshift.build.source-location": "https://github.com/openshift/console"

I have just confirmed that the "Operator Management" section works perfectly fine as a namespace admin (after `operatorgroups` is added to the aggregated `admin` ClusterRole, fixed in https://github.com/operator-framework/operator-lifecycle-manager/pull/816). Screenshot here (https://user-images.githubusercontent.com/11700385/57158645-edeecd00-6db1-11e9-9bfa-e440309ca7b7.png). This issue should be closed.

Moving to POST for https://github.com/operator-framework/operator-lifecycle-manager/pull/816 is open.

Hi, Alec, Evan

I used the OLM version below for testing, which contains that fixed PR:
OLM version: io.openshift.build.commit.id=8218b5933c6191f310468a20cb5cdabbbd4c4009
Cluster version is 4.1.0-0.nightly-2019-05-08-012425

But, the common user still could not see the `Operator Management` section on the Web. The screenshot is here: https://user-images.githubusercontent.com/15416633/57361379-ddbe5f80-71ae-11e9-99a7-fee73b372a70.png
That means the common user cannot operate the Subscriptions object on the Web although they have the full permission.

mac:~ jianzhang$ oc whoami
pm2

The namespace admin permissions about the OLM:
mac:~ jianzhang$ oc get clusterrole admin -o yaml
...
rules:
- apiGroups:
  - operators.coreos.com
  resources:
  - subscriptions
  verbs:
  - create
  - update
  - patch
  - delete
- apiGroups:
  - operators.coreos.com
  resources:
  - clusterserviceversions
  - catalogsources
  - installplans
  - subscriptions
  verbs:
  - delete
- apiGroups:
  - operators.coreos.com
  resources:
  - clusterserviceversions
  - catalogsources
  - installplans
  - subscriptions
  - operatorgroups
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - packages.operators.coreos.com
  resources:
  - packagemanifests
  verbs:
  - get
  - list
  - watch
...

@Evan
One more question, what's the purpose of granting the permission of the "packagemanifest" to admin? How the common user use this packagemanifest?
mac:~ jianzhang$ oc get packagemanifest
NAME            CATALOG         AGE
packageserver   OLM Operators   3h1m

> One more question, what's the purpose of granting the permission of the "packagemanifest" to admin? How the common user use this packagemanifest?

PackageManifest is the API that's shown on the CatalogSource page (it exposes the data that's in catalogs for view by users). 

From here: https://github.com/openshift/console/blob/master/frontend/public/components/nav.jsx#L353-L359 - you can see that the UI should show Operator Management if the user has packagemanifest list and operatorgroup list, which the admin user clearly does now.

From the information you provided, it was not clear that your user (`pm2`) is actually bound to the role `admin` in the namespace you're using `pm2`. Could you verify that and try again?

Since the admin role now has all of the permissions listed in the console code, I'm going to move this back to the console team since I see no action that OLM can take to resolve the UI issue.

Console is currently checking whether users can list these resources at the cluster scope, which is why the menu isn’t showing up.

This change relaxes the RBAC checks:

https://github.com/openshift/console/pull/1545

Evan,

Thanks for the detailed explanation. I got it.

> From the information you provided, it was not clear that your user (`pm2`) is actually bound to the role `admin` in the namespace you're using `pm2`. Could you verify that and try again?
Sure, as below, it did bound the clusterrole `admin` in the namespace `pm2`.
mac:~ jianzhang$ oc whoami
pm2
mac:~ jianzhang$ oc project
Using project "pm2" on server "https://api.qe-jiazha-0508.qe.devcluster.openshift.com:6443".
mac:~ jianzhang$ oc get role
No resources found.
mac:~ jianzhang$ oc get rolebinding
NAME                    AGE
admin                   18h
system:deployers        18h
system:image-builders   18h
system:image-pullers    18h
mac:~ jianzhang$ oc get rolebinding admin -o yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  creationTimestamp: "2019-05-08T08:06:05Z"
  name: admin
  namespace: pm2
  resourceVersion: "48310"
  selfLink: /apis/rbac.authorization.k8s.io/v1/namespaces/pm2/rolebindings/admin
  uid: 20c1f507-7168-11e9-9c63-0630efe1be84
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: pm2

Hi, Evan

> In that case, I think it makes sense to have an access level that allows subscription to an operator (if it has been explicitly been made available via a catalog).

One more question, if the common user can create the subscription object, but why not grants the `create` permission of `OperatorGroup`? You know, the subscription will fail if no the OperatorGroup object.

...
- apiGroups:
  - operators.coreos.com
  resources:
  - clusterserviceversions
  - catalogsources
  - installplans
  - subscriptions
  - operatorgroups
  verbs:
  - get
  - list
  - watch

Creating or editing an operatorgroup requires higher-than-namespace-admin privileges (because OperatorGroups target other namespaces and control how extensions are installed into the control plane). Creating operatorgroups means you can start placing things in other namespaces that you don't own.

Evan,

Yes, thanks! I see. Based on my understanding, for now, the workflow of creating Operator for the common users is:
Step1, cluster-admin users create CatalogSource/OperatorGroup objects in common users' namespace first.
Step2, common users can create the `subscription` to install operators.

But, I have some concerns here:
1, for step1, it's very difficult for the cluster-admin users to create the correct CatalogSource object. You know, they have to create the CatalogSourceConfig object first.
2, for step2, it's difficult for the common users to specify the correct values, (such as startingCSV, source, channel, etc.) in his subscription file too.
3, by now, we don't have the workflow documents for creating operators for the common users.

What's the reason for the design of this workflow? For me, I don't think this is a good experience for users. I insist that only the cluster-admin users can create the operators and the common user just use the service provided by the operators is good. Correct me if I'm wrong. Thanks!

Change back to OLM component first.

I'm moving to modified since the bug has been addressed and all relevant PRs have merged.

I've asked Daniel Messer to review Jian's concerns about the UX, and we will track that in Jira if work needs to be done to address it.

Hi Jian,

addressing your concerns below:

1) in recent OperatorHub implementations we have moved away from creating the CatalogSourceConfig object to present CatalogSources. Cluster-admins now omit this step and place an OperatorSource directly into the namespace, creating a CatalogSource object in the process.

2) agreed, that the Subscription API could be even easier to deal with. I can imagine that we provide defaults for startingCSV (use the latest of the channel) and the channel (use the defaultChannel) if we are not doing this already. The source is the name of the CatalogSource which is the same as the name of OperatorSources. The packageserver API can be enhanced to show the origin CatalogSource.

3) agreed, we need proper docs for all of this.

The reason why it’s not just cluster-admin who should be able to do this is hosted clusters, where the tenant gets some level of admin access but not cluster-admin, in order for the backing SRE team to reasonably be able to make some guarantees. OpenShift Dedicated is one example.
IMHO it is legitimate for an administrative persona to be able to install Operators in a constrained way, that ensures the cluster’s stability at large is not impacted. We have made such constraints available with an OperatorGroups that carry a ServiceAccount, defining maximum permissions and by leaving the creation of an OperatorGroup a cluster-admin-only use case.

Hi, Daniel

Many thanks for your details explanation.

1) Yes, I noticed that. I saw we still retain the CSC, is it in order to compatible with the 4.1？ Or will have new features based on this resource？ 

> IMHO it is legitimate for an administrative persona to be able to install Operators in a constrained way, that ensures the cluster’s stability at large is not impacted. 

Yes, you're right. I see. Now, only cluster-admin user can create the `operatorgroup`, and the common users can create the `subscription`, that means they can install the operators.
One question, do we implement this on Web console? I could not find a place to file a `subscription` for the common user.
Here is a screenshot: https://user-images.githubusercontent.com/15416633/61704895-5dec6e00-ad77-11e9-9b1e-c30b2df10da1.png

One more question, seems like duplicated settings for `packagemanifests` resource, like below:
mac:~ jianzhang$ oc get clusterrole admin -o yaml
...
rules:
- apiGroups:
  - operators.coreos.com
  resources:
  - subscriptions
  verbs:
  - create
  - update
  - patch
  - delete
- apiGroups:
  - operators.coreos.com
  resources:
  - clusterserviceversions
  - catalogsources
  - installplans
  - subscriptions
  verbs:
  - delete
- apiGroups:
  - operators.coreos.com
  resources:
  - clusterserviceversions
  - catalogsources
  - installplans
  - subscriptions
  - operatorgroups
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - packages.operators.coreos.com
  resources:
  - packagemanifests
  verbs:
  - get
  - list
  - watch
...
- apiGroups:
  - packages.operators.coreos.com
  resources:
  - packagemanifests
  verbs:
  - create
  - update
  - patch
  - delete

Change status to ASSIGNED first.

Hi Jian,

The duplication you're seeing is because we're using role aggregation for the `admin` role, which can do everything `edit` can and everything `view` can (see the verbs are different, they're not duplicated)

Hi, Evan

Sorry, my mistake. But I still have a concern about the Web console as I asked in comment 33:

> One question, do we implement this on Web console? I could not find a place to file a `subscription` for the common user.
Here is a screenshot: https://user-images.githubusercontent.com/15416633/61704895-5dec6e00-ad77-11e9-9b1e-c30b2df10da1.png

Move on the Web Console team first. Change status to ASSIGNED.

Sam, the project admins can see installed Operators page now but still cannot create instance of installed operator.
error likes: Restricted Access
customresourcedefinitions.apiextensions.k8s.io "sparkclusters.radanalytics.io" is forbidden: User "hasha1" cannot get resource "customresourcedefinitions" in API group "apiextensions.k8s.io" at the cluster scope

$ oc get clusterrole admin -o yaml |grep "apiextensions.k8s.io" -A 7
  - apiextensions.k8s.io
  resourceNames:
  - sparkapplications.radanalytics.io
  resources:
  - customresourcedefinitions
  verbs:
  - get
- apiGroups:
--
  - apiextensions.k8s.io
  resourceNames:
  - sparkclusters.radanalytics.io
  resources:
  - customresourcedefinitions
  verbs:
  - get
- apiGroups:
--
  - apiextensions.k8s.io
  resourceNames:
  - sparkhistoryservers.radanalytics.io
  resources:
  - customresourcedefinitions
  verbs:
  - get
- apiGroups:

from the admin rolebinding, it seems like it works as expected for console part. Not sure if I can verify this bug for now?

Hi, Han

For the issue in comment 38, please see bug 1744488.
For this bug, I think the end-users should see the "Installed Operator" section on the Web console.
And, if the cluster-admin users create the OperatorGroup object in the end-users' namespace, then, those end-users can create an operator on the Web console.

In addition, seems like we should not hidden the operator hub page for project admin.
$ oc get clusterrole admin -o yaml  |grep packages.operators.coreos.com -A 10
  - packages.operators.coreos.com
  resources:
  - packagemanifests
  - packagemanifests/icon
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - packages.operators.coreos.com
  resources:
  - packagemanifests
  verbs:
  - create
  - update
  - patch
  - delete
From backend design, it appears allow admins to get packagemanifests but console hidden the operatorHub page for admins.
From Comment 41, it means the project admin can install operator to its own project as long as the project has  OperatorGroup object.

Only cluster admins should see OperatorHub. This is by design. The RBAC permissions in comment #42 are not sufficient for the OperatorHub page.

comment #38 is bug 1744488 and a separate RBAC issue.

The project admin could see the installed operators.
Verify this bug. 4.2.0-0.nightly-2019-09-02-172410

Hi, Samuel

> Only cluster admins should see OperatorHub. This is by design.

As the design, the end-users can install the operators in themselves namespaces after the cluster-admin users create the OperatorGroup for them.
If they cannot see the OperatorHub, so where can they install the operators from?

CC Daniel

tldr: Operators don't play nice with namespaces, which causes problems for namespace admins

The problem with self-service OperatorHub for namespace admins is that some Operators can be installed cluster-wide (which means the `Subscriptions` go in "openshift-operators"), and installing them again in the single namespace will cause problems. So that is why OperatorHub requires cluster-admin type of permissions [0], in order to check if certain cluster-wide Operators are already installed and "available" in the current namespace. 

The intended UX is that namespace admins request a cluster admin make a given Operator available in their namespace. I believe there are plans for a UI flow for this (right now it would probably be an email or IRC message). I hope this explanation along with the new pull request [1] will allow this bug to be closed until new UX is designed for OLM.

[0] https://github.com/openshift/console/blob/37200e2ef4456da9a4e004f4066ba2fecc035857/frontend/public/components/operator-hub/operator-hub-page.tsx#L83
[1] https://github.com/openshift/console/pull/2580

Hi, Alec

Thanks for your details.

> I believe there are plans for a UI flow for this (right now it would probably be an email or IRC message). I hope this explanation along with the new pull request [1] will allow this bug to be closed until new UX is designed for OLM.

I think above PR already merged in 4.2, but I'm confused that the common users still cannot see the OperatorHub section on the Console.
For me, I think the common users should see the OperatorHub section. For better tracing this issue, I split it to bug 1754810. Thanks!

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, 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-2019:2922

Clearing needinfo as the OperatorHub question was split into a separate bug.