Upgrade-crds pod is erroring when attempting to validate crd apis

[Mo0rBy]

What steps did you take and what happened:
Tried to install secrets-store-csi-driver Helm chart.
1st pod I see being deployed is secrets-store-csi-driver-upgrade-crds-zkdc2 with a crds-upgrade container.
The crds-upgrade container instantly fails with the following error:

crds-upgrade error validating "crds/secrets-store.csi.x-k8s.io_secretproviderclasses.yaml": error validating data: failed to download openapi: Get "https://172.20.0.1:443/openapi/v2?timeout=32s": dial tcp 172.20.0.1:443: connect: connection refused; if you choose to ignore these errors, turn validation off with --validate=false
crds-upgrade error validating "crds/secrets-store.csi.x-k8s.io_secretproviderclasspodstatuses.yaml": error validating data: failed to download openapi: Get "https://172.20.0.1:443/openapi/v2?timeout=32s": dial tcp 172.20.0.1:443: connect: connection refused; if you choose to ignore these errors, turn validation off with --validate=false
Stream closed EOF for cluster-addons/secrets-store-csi-driver-upgrade-crds-tzshc (crds-upgrade)

What did you expect to happen:
I expect the installation to happen with no issues (mainly for the crds-upgrade pod to be able to pull the relevant data and continue its process).

Anything else you would like to add:
I'm not actually sure where this crds-upgrade pod is coming from, as the Helm chart does not show any Deployment or even a Pod yaml for it, but I'm sure it's for this installation as it refreshes whenever I try to re-install and the error message fits.

Which provider are you using:
AWS, but this is installing the base package, not AWS's additional package to interact with Secrets Manager

Environment:

• Secrets Store CSI Driver version: (use the image tag): registry.k8s.io/sig-storage/csi-node-driver-registrar:v2.11.1
• Kubernetes version: (use kubectl version): v1.30.3-eks-2f46c53

[Mo0rBy]

Done some more looking and found that this pod is being created by a Job and the correct image tag for this container is registry.k8s.io/csi-secrets-store/driver-crds:v1.4.5, NOT what I put in the original post.

I upgraded from 1.4.4 to 1.4.5 to try and see of that would fix this, so I get the same behaviour with image tag 1.4.4

[Mo0rBy]

I have found a similar issue, but unfortunately it went stale and so there is no documented solution within the thread.

I have the ClusterRole described in that thread:

[Mo0rBy]

I've just done a quick check with kubectl api-resources and we already have the CRD's available from the previous versions installation:

❯ kubectl api-resources | rg secrets-store
secretproviderclasses                            secrets-store.csi.x-k8s.io/v1            true         SecretProviderClass
secretproviderclasspodstatuses                   secrets-store.csi.x-k8s.io/v1            true         SecretProviderClassPodStatus

[Mo0rBy]

I've used a temporary solution of disabling the Helm install hook, so my installation does not wait for the install hook to pass first.

This means I have the failing Job + Pod for upgrade-crds still, but I dont care because I have all the actual secrets-store-csi-river DaemonSet pods so I have what I need.

Will leave this issue open as the crds-upgrade pod should still be working.

[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