Bug 1743985

Summary: non-admin can not use vm wizard in its own project
Product: OpenShift Container Platform Reporter: Guohua Ouyang <gouyang>
Component: Console Kubevirt PluginAssignee: Tomas Jelinek <tjelinek>
Status: CLOSED DUPLICATE QA Contact: Guohua Ouyang <gouyang>
Severity: low Docs Contact:
Priority: low    
Version: 4.2.0CC: aos-bugs, bparees, cnv-qe-bugs, danken, fkrepins, fsimonce, gouyang, sgordon, tjelinek
Target Milestone: ---   
Target Release: 4.4.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-02-27 12:28:55 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:
Bug Depends On: 1721444    
Bug Blocks:    
Attachments:
Description Flags
error_nonadmin none

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 ***