Created attachment 1635721 [details] screenshot Description of problem: Consider user creating 2 namespaces and a VM via VM Wizard in one of those namespaces. Then when the VM is cloned to the other namespace, the cloning fails with permission error: Error "Authorization failed, message is: User system:serviceaccount:rhrazdil-test:default has insufficient permissions in clone source namespace rhrazdil-test-cloneto" for field "spec.dataVolumeTemplates[0]". It is possible to clone the VM to the same namespace (where the source/original VM is). Version-Release number of selected component (if applicable): OCP Cluster 4.3.0-0.nightly-2019-10-29-140935 UI running from master locally, commit 8a44a1fef0ce1ebb932d8561ab8ce0ac8d32aec0 How reproducible: 100% Steps to Reproduce: 0. log in as kubeadmin 1. create 2 namespaces 2. Create a VM with VM Wizard in one of created namespaces, see attached yaml for example 3. Clone the VM to the other created namespace Actual results: cloning fails with permission error Expected results: cloning should pass Additional info:
Created attachment 1635722 [details] examle VM
This is not a bug. The user kube:admin is missing permissions to clone data volumes from one namespace to another. For it to work I had to create ClusterRole and Rolebinding in the source namespace (the namespace from which I try to clone the VM) ``` apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: datavolume-cloner rules: - apiGroups: ["cdi.kubevirt.io"] resources: ["datavolumes/source"] verbs: ["*"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: allow-clone-to-user namespace: <Source namespace> subjects: - kind: ServiceAccount name: default namespace: <Destination namespace> roleRef: kind: ClusterRole name: datavolume-cloner apiGroup: rbac.authorization.k8s.io ```
Re-open, users should have the option to make operations across namespaces they own out of the box, without manual rbac configuration. Moving the bug to Storage.
Due to security considerations when breaching namespace boundaries we are requiring the rbac permissions to be in place. We expect CNV documentation to provide further information about this.
New content has been created to cover this, and included as a prerequisite to the cloning user stories. PR: https://github.com/openshift/openshift-docs/pull/18609 The preview build for the new content can be viewed here: https://cnv-bz1771927-rbac-clone--ocpdocs.netlify.com/openshift-enterprise/latest/cnv/cnv_users_guide/cnv-enabling-user-permissions-to-clone-datavolumes.html
DataVolumes spelling is wrong. It should be camel case, see next two chapters. Also I'm not sure about its placement. What do you think about making it a part of "Cloning a virtual machine disk into a new DataVolume" and next "Cloning Templates" chapters? Since * current RBAC section mentions DataVolumes, but only next two chapters have a subsection "About DataVolumes" explaining what it is and how it is used. * two next sections about cloning have a requirement about RBAC or another way is to include "About DataVolumes" subsection in RBAC section?
PR updated: https://github.com/openshift/openshift-docs/pull/18609 * Fixed the case for DataVolumes. * Added 'About DataVolumes' module into RBAC section Although it's not apparent in this PR, the structure of the cnv content will be restructured prior to 2.2 release (WIP PR is here: https://github.com/openshift/openshift-docs/pull/18366/files), which will make this content much easier to navigate and discern at a glance.
Please add 'fixed in version'
Looks good, thanks Andrew.
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-2020:0307