The reason why vsphere plugin needs glibc is because the VDDK dependency requires it.

Ideally, velero-plugin-for-vsphere, init container running inside velero pod, should be able to get rid of glibc, as the consumption of VDDK has been offloaded to data-manager-for-plugin image.

But, before making it seamlessly working, we might need to make some changes in Makefile and Dockerfiles and verify it seriously. Overall, it is a non-trivial task. We should consider working on it next @xing-yang

@xinyanw409 Can you take a look?

@ywk253100 Can you provide links to the CVEs? We want to see what they are and the severity of them.

Here is the scan result of velero main image

Hi, are there any progress on this ticket?

@xinyanw409 I saw a new PR is submitted, but seems it contains no change for removing the VDDK dependency from vsphere-plugin itself, please see my comment cc @xing-yang

For 1.4.1 we have changed our dockerfile to use photon-4.0 with which reduces the vulnerability. For the pending PR we're going to split our datamgr into two parts so eventually the velero plugin and backup-driver can get rid of the vddk. I'm scan and evaluate the current plugin image first to see if there's any high CVE issues. If yes we'll consider using a separate go.mod for datamgr, thanks.

@ywk253100 As Xinyan said, we'll move datamgr into a separate go module if her current PR does not resolve the CVEs.

Let me explain it in more detail to make sure we understand the issue clearly, correct me if I'm wrong.

When installing Velero, the vSphere-plugin(which contains three parts: velero-plugin, data-manager, backup-driver), let's call it vSphere plugin to distinguish from velero-plugin, runs as an init container of Velero pod.

The init container does two works:

1. Copy the velero-plugin binary into a volume shared with the velero container, so after this step, the velero binary and velero-plugin binary are in the same container.
2. Start data-manager and backup-driver.

The current init container works well and has nothing to do with which base image the Velero uses.

When doing the backup/restore, the velero binary starts the velero-plugin binary and calls its functions via gRPC, this is the part that needs the Velero base image contain glibc because the velero-plugin itself dependents the VDDK library.

The key of the issue is that velero-plugin runs inside the Velero container and it needs glibc, so the fix should remove the dependency from velero-plugin. But seems there are no changes for this part in the PR.

So we need to test backup/restore after making this change. @ywk253100 What Velero image can we test with? You don't have a Velero image that does not use base-debian yet, right?

We can provide one Velero image which uses the static distroless as the base image

@xing-yang @xinyanw409 You can use redenval/velero:v1.9.3-distroless-static to do the test