Allow SecretProviderClass to successfully deploy with an empty secret/parameter list.

[OS-marcoguilherme]

Describe the bug
Pod doesn't start if the Secret Provider Class it uses for a volume mount does not contain any secret/object. Got the following error: failed to mount secrets store objects for pod <pod_name>, err: missing object version.

To Reproduce

Created a k8s deployment that mounts secrets from an AWS secret provider class, and the initial version of that SPC does not contain any secret/object. Got the following error in the pod: failed to mount secrets store objects for pod <pod_name>, err: missing object version.

E.g.

spec:
  parameters:
    objects: '[]'
  provider: aws

Expected behavior
Pod should start and run even if the Secret Provider Class it uses for a volume mount does not contain any secret/object. The mount path would be empty in that case.

Environment:
Kubernetes version: v1.31.12-eks-e386d34

Additional context
Issue seems to be in https://github.com/aws/secrets-store-csi-driver-provider-aws/blob/secrets-store-csi-driver-provider-aws-1.0.0/server/server.go#L191. If var ov []*v1alpha1.ObjectVersion was set to an empty array instead of nil in case of empty objects in the SPC, no error would be thrown.

[simonmarty]

Why would you ever want to launch a pod with an empty SecretProviderClass attached to it? Imo this falls outside of valid input. We can talk about improving the error message or the validation logic but I feel pretty confident saying this should cause a pod deployment failure.

[OS-marcoguilherme]

Why would you ever want to launch a pod with an empty SecretProviderClass attached to it?

This would be useful for use cases where a deployment does not have control over which secrets exist in a given cluster/environment (there could either be or not be secrets at the time the pod starts).

[OS-tariqabbasi]

Why would you ever want to launch a pod with an empty SecretProviderClass attached to it? Imo this falls outside of valid input. We can talk about improving the error message or the validation logic but I feel pretty confident saying this should cause a pod deployment failure.

We have a use case where an application needs to mount secrets but the secrets are created/deleted dynamically by other components, an operator periodically reconciles the SecretProviderClass. We have a scenario where the SecretProviderClass needs to be empty initially and the secrets will be added later.

Is there any harm in an empty SecretProviderClass being considered as valid input? It's much easier to update an SPC (i.e. an existing mount point) rather than updating (potentially multiple) deployments to add/remove a mount point.

[simonmarty]

One concern I have is that this sort of false positive can lead to hair pulling debugging sessions. We're going to investigate prior art in the k8s space to see if there's consensus on what a no-op deployment file should do by default.

We have a scenario where the SecretProviderClass needs to be empty initially and the secrets will be added later.

One way around this is conditionally deploying your SPC.

[OS-tariqabbasi]

We're going to investigate prior art in the k8s space to see if there's consensus on what a no-op deployment file should do by default.

Thanks.

One way around this is conditionally deploying your SPC.

We considered that but since CSI volumes can't be optional (only available for ConfigMap and Secret) it would require all of our deployment templates to have conditional mounts and frequent Helm reconciliation which is far from ideal. Syncing the SPC to a Secret is also not possible for other reasons.

[simonmarty]

k8s slack discussion thread: https://kubernetes.slack.com/archives/C013PUP2WRK/p1759774996424369

[OS-tariqabbasi]

k8s slack discussion thread: https://kubernetes.slack.com/archives/C013PUP2WRK/p1759774996424369

Hi @simonmarty, thanks for promoting this discussion, there seems to be agreement that this would be up to the provider implementation. If we were to add a parameter at the provider level to allow/disallow the empty list (with default being disallow to keep existing behaviour) as suggested in the thread, then would that address your concerns?

For example:

spec:
  provider: aws
  parameters:
    allowEmptyObjects: true
    objects: '[]'

[simonmarty]

That's the most likely approach at this time. We're still investigating on our side to make sure we're not following a k8s antipattern by doing this. This is being tracked internally.