When trying to deploy multiple instances of SecretProviderClass to the same Namespace only one gets deployed and the Pod Deployment Fails

[ic-mgriehm]

What steps did you take and what happened:
When trying to deploy multiple instances of SecretProviderClass to the same Namespace only one gets deployed and the Pod Deployment Fails

What did you expect to happen:
Both SecretProviderClasses get created, mounted to Pod, and the Pod can pull in Secrets from Each KeyVault as Environment variables in the Pod.

Anything else you would like to add:
The Pod tries to deploy but a Failure Event is reported that one of the SecretProviderClasses cannot be found and when we use kubectl to list the SecretProviderClasses in the Namespace only one appears, and normally it is the second one listed in the Kubernetes Manifest.

Which provider are you using:
Azure Key Vault

Environment:

• Secrets Store CSI Driver version: (use the image tag):
  • mcr.microsoft.com/oss/kubernetes-csi/csi-node-driver-registrar:v2.8.0
  • mcr.microsoft.com/oss/kubernetes-csi/secrets-store/driver:v1.3.4-1
  • mcr.microsoft.com/oss/kubernetes-csi/livenessprobe:v2.10.0
• Kubernetes version: (use kubectl version): 1.28.3

[aramase]

When trying to deploy multiple instances of SecretProviderClass to the same Namespace only one gets deployed and the Pod Deployment Fails

What does multiple instances of SecretProviderClass here mean? Are you deploying 2 instances with the same name in the namespace?

[ic-mgriehm]

@aramase 2 instances with different names in the same namespace.

[aramase]

When trying to deploy multiple instances of SecretProviderClass to the same Namespace only one gets deployed and the Pod Deployment Fails

The issue description doesn't provide clear information about the error. Please provide example manifests and repro steps.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[aramase]

/close

Closing this issue due to insufficient information. Feel free to reopen with #1449 (comment).

[k8s-ci-robot]

@aramase: Closing this issue.

In response to this:

/close

Closing this issue due to insufficient information. Feel free to reopen with #1449 (comment).

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.