Bug 1743985 - non-admin can not use vm wizard in its own project
Summary: non-admin can not use vm wizard in its own project
Keywords:
Status: CLOSED DUPLICATE of bug 1721444
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Console Kubevirt Plugin
Version: 4.2.0
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: ---
: 4.4.0
Assignee: Tomas Jelinek
QA Contact: Guohua Ouyang
URL:
Whiteboard:
Depends On: 1721444
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-08-21 05:54 UTC by Guohua Ouyang
Modified: 2020-02-27 12:28 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-02-27 12:28:55 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
error_nonadmin (66.40 KB, image/png)
2019-08-21 05:54 UTC, Guohua Ouyang
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Github openshift console pull 2457 0 'None' closed kubevirt: fix VMWizard permissions 2021-01-28 00:21:42 UTC

Description Guohua Ouyang 2019-08-21 05:54:04 UTC
Created attachment 1606368 [details]
error_nonadmin

Description of problem:
Create a non-admin user, login with the user and create a project.
Then try to use vm wizard, it pops up an error on the top of the browser and prevent the user to use the wizard. However, the project is created by non-admin user, it should be able to use the wizard.

"virtualmachines.kubevirt.io is forbidden: User "test" cannot list resource "virtualmachines" in API group "kubevirt.io" at the cluster scope"

Version-Release number of selected component (if applicable):
hco-bundle-registry:v2.1.0-13
OpenShift Version 4.2.0-0.nightly-2019-08-15-073735

How reproducible:
100%

Steps to Reproduce:
1. create a non-admin user
2. login with the user 
3. create a project
4. go Workloads -> Virtual Machines
5. click "Create"

Actual results:
non-admin can not use vm wizard in its own project

Expected results:
non-admin can be able to use vm wizard in its own project

Additional info:
Steps to create a non-admin user:

TESTHTPASSWD="./test.htpasswd"
htpasswd -c -B -b ${TESTHTPASSWD} test test
oc create secret generic test-htpass-secret --from-file=htpasswd=${TESTHTPASSWD} -n openshift-config

cat <<EOF | kubectl create -f -
apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
  name: cluster
spec:
  identityProviders:
  - name: test
    mappingMethod: claim 
    type: HTPasswd
    htpasswd:
      fileData:
        name: test-htpass-secret
EOF

Comment 1 Guohua Ouyang 2019-08-21 05:56:37 UTC
"virtualmachines.kubevirt.io is forbidden: User "test" cannot list resource "virtualmachines" in API group "kubevirt.io" at the cluster scope".

The message is not correct as well, it's at the user's own project, not at the cluster scope.

Comment 2 Guohua Ouyang 2019-08-21 06:02:31 UTC
"Create pod" is fine, so it's kubevirt-web-ui own issue.

Comment 3 Guohua Ouyang 2019-08-21 06:12:56 UTC
For OCP objects like pods and deployments: 
If the user just have 'view' permission, the button 'Create Pod' is not showing at all.
If the user have 'edit' permission, the button 'Create Pod' is there for using.

Comment 5 Guohua Ouyang 2019-09-06 06:14:32 UTC
Now the error is 'network-attachment-definitions.k8s.cni.cncf.io is forbidden: User "test" cannot list resource "network-attachment-definitions" in API group "k8s.cni.cncf.io" in the namespace "test"', is it an environment issue or just another error need to be fixed?

4.2.0-0.nightly-2019-09-04-142146
HCO 2.1.0-29

Comment 6 Filip Krepinsky 2019-09-06 11:30:40 UTC
Environment issue; list/watch rights are required for the resource mentioned in the namespace test.

Comment 7 Guohua Ouyang 2019-09-16 23:40:35 UTC
It's the same error when run the same command from command line:

$ oc whoami
test

$ oc get network-attachment-definitions
Error from server (Forbidden): network-attachment-definitions.k8s.cni.cncf.io is forbidden: User "test" cannot list resource "network-attachment-definitions" in API group "k8s.cni.cncf.io" in the namespace "testv"

The question is should the non-admin has the permission to list the resource "network-attachment-definitions"? If the answer is yes, then it's a virt bug. If it's no, then it should not try to list such resource on UI.

Comment 8 Filip Krepinsky 2019-09-17 11:21:27 UTC
IMO they should have the permission to list network-attachment-definitions in their namespace, because they are needed for vm network interfaces

Comment 9 Guohua Ouyang 2019-09-17 13:05:59 UTC
It makes sense, move the bug to cnv -> virt and set it to urgent as it affects UI.

Comment 10 Fabian Deutsch 2019-09-17 15:26:23 UTC
Dan, is this a network op permission issue?

Comment 11 Dan Kenigsberg 2019-09-17 15:53:53 UTC
I believe that the remaining problem here is bug 1721444, which is no longer targeted to OCP-4.2, unfortunately.

Filip, can you work around this in the UI, e.g by allowing the end user to type in the network-attachement-definition name in case she cannot list any?

Comment 12 Tomas Jelinek 2019-09-18 09:30:24 UTC
> can you work around this in the UI, e.g by allowing the end user to
> type in the network-attachement-definition name in case she cannot list any?

Unfortunately it is too late for this now. It is an actual change in the design of the screen (e.g. not just a bugfix) and 2 days before the final freeze of the repo it is not possible to get such a change in.

Comment 13 Guohua Ouyang 2019-09-18 12:16:59 UTC
@Tomas, Do you think is this a release blocker? Because the non-admin user cannot use the wizard at all.

Comment 15 Dan Kenigsberg 2019-09-18 12:30:41 UTC
@Federico, this is not fixable in one day. Our only hope is to convince OCP to fix underlying bug. This bug is horrible for our GUI, but I'm not sure it is a HTB blocker.

@Tomas, is there a similar bug affecting Pod-related GUI? Having one may convince OCP to fix the underlying bug 1721444 in OCP-4.2.0.

Comment 16 Federico Simoncelli 2019-09-18 12:35:10 UTC
@Dan the fix is not in something we ship in the CNV errata so this is not holding our release (AFAIK)?

Do you want to reassign to the UI team so it's more evident?

Comment 17 Dan Kenigsberg 2019-09-18 12:37:09 UTC
moving back to UX for tracking or a workaround

Comment 18 Tomas Jelinek 2019-09-18 12:39:44 UTC
(In reply to Dan Kenigsberg from comment #15)
> @Federico, this is not fixable in one day. Our only hope is to convince OCP
> to fix underlying bug. This bug is horrible for our GUI, but I'm not sure it
> is a HTB blocker.
> 
> @Tomas, is there a similar bug affecting Pod-related GUI?

nope, they dont use this for pods.

Comment 27 Tomas Jelinek 2020-02-14 08:57:37 UTC
In CNV 2.3 the problem is not anymore that you can not open the wizard. Only that if you do not have access to the NADs, you will not be able to list them meaning will not be able to create a secondary NIC. That is an expected behavior, would not block OCP on it, lowering priority.

Comment 28 Tomas Jelinek 2020-02-27 12:28:55 UTC
no need to track it separately, marking it as duplicate.

*** This bug has been marked as a duplicate of bug 1721444 ***


Note You need to log in before you can comment on or make changes to this bug.