Support copying namespace-scoped secrets for backup PVC provisioning

[shubham-pampattiwar]

Summary

Add support for copying namespace-scoped secrets and configmaps from the source PVC namespace to the Velero namespace during datamover backup PVC creation. This enables backup of CSI volumes that use encrypted StorageClasses requiring namespace-scoped secrets and configmaps (e.g., ODF/ceph-csi with Vault KMS).

New secretNames and configMapNames fields in backupPVCConfig allow users to specify which resources should be copied:

{
  "backupPVC": {
    "ocs-storagecluster-ceph-rbd-encrypted": {
      "secretNames": ["ceph-csi-kms-token"],
      "configMapNames": ["ceph-csi-kms-config"]
    }
  }
}

The copy happens in the DataUpload controller after acceptDataUpload(), so only the accepting node handles it:

1. Copy: Secrets and configmaps are copied from the source namespace to the Velero namespace with a tracking label (velero.io/backup-pvc-secret)
2. Collision handling: If a resource with the same name but different data already exists (from another namespace's DataUpload), the DataUpload fails with a clear error message
3. Same-namespace: If the existing resource has identical data, it's a no-op (concurrent backups from the same namespace work in parallel)
4. Cleanup: Secrets and configmaps are deleted in CleanUp() using label-based lookup after the DataUpload completes

Does your change fix a particular issue?

Fixes #9879

Please indicate you've done the following:

• Accepted the DCO. Commits without the DCO will delay acceptance.
• Created a changelog file (make new-changelog) or comment /kind changelog-not-required on this PR.
• Updated the corresponding documentation in site/content/docs/main.

[netlify]

👷 Deploy request for velero pending review.

Visit the deploys page to approve it

Name	Link
🔨 Latest commit	ef81f09

[codecov]

Codecov Report

❌ Patch coverage is 39.00000% with 61 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
pkg/util/kube/secrets.go	40.22%	48 Missing and 4 partials ⚠️
pkg/controller/data_upload_controller.go	10.00%	8 Missing and 1 partial ⚠️

📢 Thoughts on this report? Let us know!

[Lyndon-Li]

This will bring a contest among all the cluster nodes, because the DU is not taken by any nodes yet.

[shubham-pampattiwar]

@Lyndon-Li Good catch. I'll move the secret copy after acceptDataUpload() so only the accepting node handles it. Does that work for you?

[Lyndon-Li]

Once a DU is accepted, there is no way to return it back and retry.

[shubham-pampattiwar]

@Lyndon-Li Since the DU can't be retried after accept, for the collision case (same secret name, different data from concurrent cross-tenant backups) the DataUpload would fail with a clear error message and the user can retry.

The collision is a narrow edge case -- it requires concurrent encrypted backups from different namespaces using the same secret name with different values. For the common cases (single tenant, same-namespace concurrent, sequential backups), there's no collision.

If we want automatic retry for the collision case, we'd need to handle it in the Accepted phase. Would you prefer we keep it simple with a fail + retry for now, or should we add the Accepted phase handling?

[shubham-pampattiwar]

Also, if you have a different approach in mind for handling this, I'm open to suggestions.

[Lyndon-Li]

The collision is a narrow edge case -- it requires concurrent encrypted backups from different namespaces using the same secret name with different values. For the common cases (single tenant, same-namespace concurrent, sequential backups), there's no collision.

For sure, I prefer a simpler approach AS LONG AS it could meet the majority cases.
However, for this judgement, I am not fully convinced --- multiple tenant is a common case, concurrent backup of multiple volumes among multiple nodes are very common. The only thing I am not sure is whether it is a common case that different tenants/namespaces would use different secrets.

[sseago]

@Lyndon-Li This could be a documented exception. Secrets for encrypted volumes should be unique cluster-wide to avoid possible failures with concurrent backups.

[shubham-pampattiwar]

@Lyndon-Li @sseago Agreed with Scott's suggestion. We can document that for concurrent multi-tenant encrypted backups, secret names should be unique per namespace. On the ceph-csi side, this is already supported via the tenantTokenName configuration in the KMS config.

So the approach would be:

• Secret copy after accept, fail on collision with a clear error message
• Document that users with concurrent cross-tenant encrypted backups should configure unique secret names per namespace

Does that work for you?