Hide Forgot
Description of problem: `oc delete all --all` hit some forbidden resources which are not in project scopes. The resource lists: installplans.operators.coreos.com catalogsources.operators.coreos.com clusterserviceversions.operators.coreos.com subscriptions.operators.coreos.com Version-Release number of selected component (if applicable): oc v4.0.0-0.94.0 kubernetes v1.11.0+3db990d20d features: Basic-Auth GSSAPI Kerberos SPNEGO Server https://***.devcluster.openshift.com:6443 kubernetes v1.11.0+c02e7fd oc get clusterversion version NAME VERSION AVAILABLE PROGRESSING SINCE version 4.0.0-0.alpha-2018-12-11-040917 False True 29m How reproducible: always Steps to Reproduce: 1.Enable allowall auth in cluster, then login cluster with common user 2.Create new project 3.Create app via `oc new-app centos/ruby-25-centos7~https://github.com/sclorg/ruby-ex.git` 4.Delete resources via `oc delete all --all` Actual results: $ oc delete all --all pod "ruby-ex-1-build" deleted replicationcontroller "ruby-ex-1" deleted service "ruby-ex" deleted deploymentconfig.apps.openshift.io "ruby-ex" deleted buildconfig.build.openshift.io "ruby-ex" deleted imagestream.image.openshift.io "ruby-25-centos7" deleted imagestream.image.openshift.io "ruby-ex" deleted Error from server (Forbidden): installplans.operators.coreos.com is forbidden: User "xiuwang" cannot list installplans.operators.coreos.com in the namespace "xiuwang": no RBAC policy matched Error from server (Forbidden): catalogsources.operators.coreos.com is forbidden: User "xiuwang" cannot list catalogsources.operators.coreos.com in the namespace "xiuwang": no RBAC policy matched Error from server (Forbidden): clusterserviceversions.operators.coreos.com is forbidden: User "xiuwang" cannot list clusterserviceversions.operators.coreos.com in the namespace "xiuwang": no RBAC policy matched Error from server (Forbidden): subscriptions.operators.coreos.com is forbidden: User "xiuwang" cannot list subscriptions.operators.coreos.com in the namespace "xiuwang": no RBAC policy matched Expected results: Should not prompt unexisted resources Additional info:
[xxia@fedora28 installer]$ oc whoami system:admin [xxia@fedora28 installer]$ oc get all --v=6 |& grep coreos.com I1211 15:30:51.864644 1345 round_trippers.go:405] GET https://....openshift.com:6443/apis/operators.coreos.com/v1alpha1/namespaces/xxia-proj/clusterserviceversions?limit=500 200 OK in 258 milliseconds I1211 15:30:52.122655 1345 round_trippers.go:405] GET https://....openshift.com:6443/apis/operators.coreos.com/v1alpha1/namespaces/xxia-proj/catalogsources?limit=500 200 OK in 256 milliseconds I1211 15:30:52.379381 1345 round_trippers.go:405] GET https://....openshift.com:6443/apis/operators.coreos.com/v1alpha1/namespaces/xxia-proj/subscriptions?limit=500 200 OK in 256 milliseconds I1211 15:30:52.636966 1345 round_trippers.go:405] GET https://....openshift.com:6443/apis/operators.coreos.com/v1alpha1/namespaces/xxia-proj/installplans?limit=500 200 OK in 257 milliseconds
Is this against a cluster brought up using the 4.0 installer? Does it still happen if you do not enable "allowall" auth in cluster? Additionally, could you attach the `oc get all --loglevel 8` output? Thanks
> Error from server (Forbidden): installplans.operators.coreos.com is forbidden: User "xiuwang" cannot list installplans.operators.coreos.com in the namespace "xiuwang": no RBAC policy matched > Error from server (Forbidden): catalogsources.operators.coreos.com is forbidden: User "xiuwang" cannot list catalogsources.operators.coreos.com in the namespace "xiuwang": no RBAC policy matched > Error from server (Forbidden): clusterserviceversions.operators.coreos.com is forbidden: User "xiuwang" cannot list clusterserviceversions.operators.coreos.com in the namespace "xiuwang": no RBAC policy matched > Error from server (Forbidden): subscriptions.operators.coreos.com is forbidden: User "xiuwang" cannot list subscriptions.operators.coreos.com in the namespace "xiuwang": no RBAC policy matched None of the following CRDs should be registering themselves to all category, Xiuwang you'll need to split this bug into appropriate teams and let them know they are unnecessarily doing this. Example for installplans: https://github.com/operator-framework/operator-lifecycle-manager/blob/bd6bc000ec6c8375ebfddf4e5f68123f9e9161a8/deploy/ocp/manifests/0.7.2/0000_30_03-installplan.crd.yaml#L24 the `all` category should not be there.
PR: https://github.com/operator-framework/operator-lifecycle-manager/pull/631 The above patch removes all four operator CRDs (noted in this bug) from the "all" category.
I'd like to clarify the expected behavior here. What permissions does the user have in the namespace, to delete "all"? OLM aggregates `delete` on its CRs to the standard kube `edit` role. So if you make a RoleBinding from user user to `edit` in the namespace, you should be able to delete all of the resources there. What I want to figure out is: 1. Is the aggregation to `edit` not working properly? 2. Is there a different role (other than `edit`) that the user in this bug report has that we should be aggregating to so that `delete` includes OLM types? 3. Should we remove the `all` category from our types (the suggested and linked solution)? Is there any documentation around what goes into the `all` category? It seems useful to see the objects provided by OLM with a `get all`, right?
> Should we remove the `all` category from our types (the suggested and linked solution)? Is there any documentation around what goes into the `all` category? It seems useful to see the objects provided by OLM with a `get all`, right? Evan, here is the current documentation we have on which resources go into the `all` category [1]. Please keep in mind that we are inclined to only prefer core resources (not CRDs) as part of this category. Adding David for any additional thoughts. 1. https://github.com/kubernetes/community/blob/master/contributors/devel/kubectl-conventions.md#rules-for-extending-special-resource-alias---all
If don't enable 'allowall' in next gen install cluster, then we need to login env with useradmin user which have system:admin role, so do not hit this forbidden issue. After enable 'allowall', my common user has admin role under project. $ oc get rolebinding NAME AGE admin 1h jenkins_edit 1h system:deployers 1h system:image-builders 1h system:image-pullers 1h
Couldn't reproduce this bug with below version $ oc get clusterversion version NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.0.0-0.alpha-2019-01-02-232508 True False 1h Cluster version is 4.0.0-0.alpha-2019-01-02-232508 $ oc get all NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/jenkins ClusterIP 172.30.234.183 <none> 80/TCP 1m service/jenkins-jnlp ClusterIP 172.30.67.114 <none> 50000/TCP 1m NAME REVISION DESIRED CURRENT TRIGGERED BY deploymentconfig.apps.openshift.io/jenkins 0 1 0 config,image(jenkins:2) NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD route.route.openshift.io/jenkins jenkins-xiuwang.apps.xiuwang.devcluster.openshift.com jenkins <all> edge/Redirect None $ oc delete all --all service "jenkins" deleted service "jenkins-jnlp" deleted deploymentconfig.apps.openshift.io "jenkins" deleted route.route.openshift.io "jenkins" deleted
Can't reproduce this bug again. $oc get clusterversion -o yaml | grep payload payload: registry.svc.ci.openshift.org/ocp/release@sha256:85736576e39221daf368cc82be51cdb2509a77d2446ed98734286fc0ea99656c $ oc get clusterversion NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.0.0-0.nightly-2019-01-15-184339 True False 3h Cluster version is 4.0.0-0.nightly-2019-01-15-184339
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:0758