Bug 1730349 - virtctl image-upload doesn't work for non-privileged users
Summary: virtctl image-upload doesn't work for non-privileged users
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Container Native Virtualization (CNV)
Classification: Red Hat
Component: Storage
Version: 2.0
Hardware: All
OS: All
high
high
Target Milestone: ---
: 2.1.0
Assignee: Michael Henriksen
QA Contact: Qixuan Wang
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-07-16 13:59 UTC by Josep 'Pep' Turro Mauri
Modified: 2019-10-31 14:09 UTC (History)
8 users (show)

Fixed In Version: hco-bundle-registry-container-v2.1.0-69 -- cdi-2.1.0-17
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-10-31 14:08:47 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Github kubevirt containerized-data-importer pull 961 None closed create aggregate cluster roles 2020-02-21 16:23:37 UTC
Red Hat Product Errata RHEA-2019:3282 None None None 2019-10-31 14:09:01 UTC

Description Josep 'Pep' Turro Mauri 2019-07-16 13:59:18 UTC
Description of problem:

When attempting to upload an image using virtctl image-upload as a user that has admin privileges in the project but is not a cluster-admin the command fails.

Version-Release number of selected component (if applicable):

$ oc version
Client Version: version.Info{Major:"4", Minor:"1+", GitVersion:"v4.1.0-201905091432+4910781-dirty", GitCommit:"4910781", GitTreeState:"dirty", BuildDate:"2019-05-09T19:19:42Z", GoVersion:"go1.11.5", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"13+", GitVersion:"v1.13.4+c62ce01", GitCommit:"c62ce01", GitTreeState:"clean", BuildDate:"2019-06-27T18:14:14Z", GoVersion:"go1.11.6", Compiler:"gc", Platform:"linux/amd64"}

$ virtctl version
Client Version: version.Info{GitVersion:"v0.17.4", GitCommit:"adfdb8c07830b99fc79d2fd1d004e862ef70979e", GitTreeState:"clean", BuildDate:"2019-06-27T14:07:33Z", GoVersion:"go1.11.5", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{GitVersion:"v0.17.4", GitCommit:"adfdb8c07830b99fc79d2fd1d004e862ef70979e", GitTreeState:"clean", BuildDate:"2019-06-27T14:08:17Z", GoVersion:"go1.11.5", Compiler:"gc", Platform:"linux/amd64"}


How reproducible:

Always

Steps to Reproduce:
1. create a project
2. create a RoleBinding that binds the 'admin' role to the user within that namespace
3. attempt to virtctl image-upload as per the description

Actual results:

$ oc whoami
demo
$ oc describe rolebindings demo-admin
Name:         demo-admin
Labels:       <none>
Annotations:  <none>
Role:
  Kind:  ClusterRole
  Name:  admin
Subjects:
  Kind  Name  Namespace
  ----  ----  ---------
  User  demo  

$ virtctl image-upload --pvc-name=cirros2 --pvc-size 40G --image-path=images/cirros-0.4.0-x86_64-disk.img.gz
PVC demo/cirros2 created
Waiting for PVC cirros2 upload pod to be running...
Pod now running
uploadtokenrequests.upload.cdi.kubevirt.io is forbidden: User "demo" cannot create resource "uploadtokenrequests" in API group "upload.cdi.kubevirt.io" in the namespace "demo"
#+end_example


Expected results:

virtctl image-upload should work

Additional info:

I believe there's a further problem: when running virtctl image-upload as a cluster-admin with verbose logging I see that the calls include this:

{"component":"virtctl","level":"info","msg":"GET https://api.ocp41.cnv.demo:6443/apis/cdi.kubevirt.io/v1alpha1/cdiconfigs/config 200 OK in 206 milliseconds","pos":"round_trippers.go:405","timestamp":"2019-07-16T15:41:26.149823Z"}

But if I attempt this as the 'demo' user (non cluster-admin) I get:

$ oc get cdiconfigs config
Error from server (Forbidden): cdiconfigs.cdi.kubevirt.io "config" is forbidden: User "demo" cannot get resource "cdiconfigs" in API group "cdi.kubevirt.io" at the cluster scope


The problem with uploadtokenrequests prevents the demo user to reach that far but I think it would hit this problem with route discovery.

Comment 3 Adam Litke 2019-09-03 19:17:44 UTC
Can you please check with the latest release?

Comment 4 Adam Litke 2019-09-03 19:19:19 UTC
@Michael, seems we may need to allow general users access to cdiconfig.

Comment 11 Qixuan Wang 2019-09-27 07:57:52 UTC
Tested with hco-bundle-registry-v2.1.0-80, CDI v2.1.0-18, I always got "the server has asked for the client to provide credentials (post uploadtokenrequests.upload.cdi.kubevirt.io)". Did I miss something? Here are my steps.


The regular is "pm1" created by https://raw.githubusercontent.com/cucushift/IDP/master/htpasswd.sh

[cnv-qe-jenkins@cnv-executor-qwang ~]$ oc whoami
pm1

[cnv-qe-jenkins@cnv-executor-qwang ~]$ virtctl image-upload --image-path=./cirros-0.4.0-x86_64-disk.img --pvc-size=200Mi --pvc-name=upload-cirros-1 --insecure
PVC bug1/upload-cirros-1 created
Waiting for PVC upload-cirros-1 upload pod to be running...
Pod now running
the server has asked for the client to provide credentials (post uploadtokenrequests.upload.cdi.kubevirt.io)


[cnv-qe-jenkins@cnv-executor-qwang ~]$ oc logs -f cdi-upload-upload-cirros-1
I0927 06:36:46.478000       1 uploadserver.go:61] Upload destination: /data/disk.img
I0927 06:36:46.478302       1 uploadserver.go:63] Running server on 0.0.0.0:8443
^C 


[cnv-qe-jenkins@cnv-executor-qwang ~]$ oc apply -f upload-token.yaml
error: You must be logged in to the server (error when creating "upload-token.yaml": the server has asked for the client to provide credentials (post uploadtokenrequests.upload.cdi.kubevirt.io))


[cnv-qe-jenkins@cnv-executor-qwang ~]$ oc auth can-i create uploadtokenrequests
yes


Then switch to the kubeadmin user to create the token. 
[cnv-qe-jenkins@cnv-executor-qwang ~]$ oc logs -f cdi-uploadproxy-b478654d7-r9sbq -n  openshift-cnv
I0927 04:48:13.036094       1 uploadproxy.go:46] Note: increase the -v level in the api deployment for more detailed logging, eg. -v=2 or -v=3
W0927 04:48:13.037187       1 client_config.go:549] Neither --kubeconfig nor --master was specified.  Using the inClusterConfig.  This might not work.
I0927 07:49:46.209760       1 uploadproxy.go:179] Received valid token: pvc: upload-cirros-admin, namespace: bug1


Switch to the regular user "pm1"

[cnv-qe-jenkins@cnv-executor-qwang ~]$ oc create rolebinding pm1-admin --clusterrole=admin --user=pm1
rolebinding.rbac.authorization.k8s.io/pm1-admin created


[cnv-qe-jenkins@cnv-executor-qwang ~]$ oc describe rolebindings pm1-admin
Name:         pm1-admin
Labels:       <none>
Annotations:  <none>
Role:
  Kind:  ClusterRole
  Name:  admin
Subjects:
  Kind  Name  Namespace
  ----  ----  ---------
  User  pm1


[cnv-qe-jenkins@cnv-executor-qwang ~]$ virtctl image-upload --image-path=./cirros-0.4.0-x86_64-disk.img --pvc-size=200Mi --pvc-name=upload-cirros-3 --insecure
PVC bug1/upload-cirros-3 created
Waiting for PVC upload-cirros-3 upload pod to be running...
Pod now running
the server has asked for the client to provide credentials (post uploadtokenrequests.upload.cdi.kubevirt.io)



PS: Now regular users have permission to view cidconfig
[cnv-qe-jenkins@cnv-executor-qwang ~]$ oc get cdiconfigs config
NAME     AGE
config   110m

Comment 12 Michael Henriksen 2019-09-27 13:30:16 UTC
apiserver was not translating "POST to "create".

Which explains why everything looks okay if you run:

[cnv-qe-jenkins@cnv-executor-qwang ~]$ oc auth can-i create uploadtokenrequests
yes

Fix here:  https://github.com/kubevirt/containerized-data-importer/pull/979

Comment 13 Natalie Gavrielov 2019-10-06 13:08:29 UTC
Verified, now upload using virtctl for a user with admin permissions to a specific namespace can upload an image.

CDI v2.1.0-21
$ virtctl version
Client Version: version.Info{GitVersion:"v0.20.8", GitCommit:"d5430eaea926b9367e19079dedfe0df5d518ef67", GitTreeState:"clean", BuildDate:"2019-10-03T11:11:52Z", GoVersion:"go1.11.5", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{GitVersion:"v0.20.8", GitCommit:"d5430eaea926b9367e19079dedfe0df5d518ef67", GitTreeState:"clean", BuildDate:"2019-10-03T12:17:34Z", GoVersion:"go1.11.13", Compiler:"gc", Platform:"linux/amd64"}

Comment 15 errata-xmlrpc 2019-10-31 14:08:47 UTC
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/RHEA-2019:3282


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