This is not a storage bug.  SSP operator is responsible for creating the roles/rolebindings to access openshift-virtualization-os-image

looks like may have to add:

subjects:
- kind: Group
  name: system:serviceaccounts
  apiGroup: rbac.authorization.k8s.io

to the role SSP creates

https://kubernetes.io/docs/reference/access-authn-authz/rbac/#role-binding-examples

Apparently serviceaccounts aren't considered authenticated users?

I will confirm...

Just tested and there are a couple of issues:

The role created by SSP has to include "system:serviceaccounts" as mentioned above.

ALSO,

kubevirt has to be updated to check group permissions as well as service account permissions

I tried adding the "system:serviceaccounts" rolebinding, but it didn't help. The auth command still failed while checking create permissions for datavolume/source.

I then tried adding the create permission for the resource datavolumes along with create permissions for the sub-resource datavolumes/source(which was already present) and that worked. So I think, just assigning permissions to sub-resources will not work, the parent resource needs to have the same permission. I am trying to find the documentation on the kubernetes documation page regarding this, will send a link when I find it.

For now I have this WIP patch
https://github.com/kubevirt/kubevirt-ssp-operator/pull/243

> I tried adding the "system:serviceaccounts" rolebinding, but it didn't help. The auth command still failed while checking create permissions for datavolume/source.

Yeah as I mention above, kubevirt changes are necessary.  They were just merged:  https://github.com/kubevirt/kubevirt/pull/4269

Modifications have been made to the kubevirt-ssp-operator as suggested. Here is the PR - https://github.com/kubevirt/kubevirt-ssp-operator/pull/243

@Ruth: The correct auth command used to verify if the serviceaccount has access to the dv/source subresource is 

oc auth can-i create datavolumes --subresource source --as system:serviceaccount:default:default -n kubevirt-os-images

Blocked by bug 1885196

Verified with kubevirt-ssp-operator-container-v2.5.0-52
1. Create golden image from UI
2. Create a VM from the UI using the wizard

- VM creation succeeds.
- PVC is cloned
- VM is running


spec:
  dataVolumeTemplates:
    - apiVersion: cdi.kubevirt.io/v1alpha1
      kind: DataVolume
      metadata:
        creationTimestamp: null
        name: fed3-rootdisk-6e2f6
      spec:
        pvc:
          accessModes:
            - ReadWriteOnce
          resources:
            requests:
              storage: 15Gi
          storageClassName: hostpath-provisioner
          volumeMode: Filesystem
        source:
          pvc:
            name: fedora32
            namespace: openshift-virtualization-os-images
  running: true
  template:
    metadata:
      creationTimestamp: null
      labels:
        flavor.template.kubevirt.io/tiny: 'true'
        kubevirt.io/domain: fed3
        kubevirt.io/size: tiny
        os.template.kubevirt.io/fedora32: 'true'
        vm.kubevirt.io/name: fed3
        workload.template.kubevirt.io/desktop: 'true'

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 (OpenShift Virtualization 2.5.0 Images), 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:5127