Add secret reference in PV annotations for ControllerModifyVolume

[nixpanic]

What type of PR is this?

Uncomment only one /kind <> line, hit enter to put that in a new line, and remove leading whitespaces from that line:

/kind api-change

/kind bug

/kind cleanup
/kind design
/kind documentation
/kind failing-test
/kind feature
/kind flake

What this PR does / why we need it:

The ControllerModifyVolume CSI procedure should be able to receive credentials if the storage provider requires them.

The values of the following keys in the StorageClass are copied into annotations of the PersistentVolume:

• csi.storage.k8s.io/controller-modify-secret-name

  volume.kubernetes.io/controller-modify-secret-name

• csi.storage.k8s.io/controller-modify-secret-namespace

  volume.kubernetes.io/controller-modify-secret-namespace

The external-resizer can use these annotations to resolve the secret that needs to be passed in ControllerModifyVolume.

Which issue(s) this PR fixes:

Related to kubernetes-csi/external-resizer#544

Special notes for your reviewer:

Approach has been discussed in a thread at #csi.

Does this PR introduce a user-facing change?:

A StorageClass can use `csi.storage.k8s.io/controller-modify-secret-name` and `csi.storage.k8s.io/controller-modify-secret-namespace` to reference the credentials that should be used to modify a volume according to the parameters of a VolumeAttributeClass.

[Madhu-1]

/lgtm

/assign @gnufied @xing-yang

[gnufied]

/lgtm

[xing-yang]

/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: nixpanic, xing-yang

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [xing-yang]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[nixpanic]

/test pull-kubernetes-csi-external-provisioner-unit

Looks like a failure unrelated to this change.

[nixpanic]

/test pull-kubernetes-csi-external-provisioner-unit

Yet an other strange failure. Earlier related to Topology of the nodes, now kind build node-image error-ed out.

[nixpanic]

/retest pull-kubernetes-csi-external-provisioner-unit

kind failures should have been addressed with kubernetes/kubernetes#135575

[k8s-ci-robot]

@nixpanic: The /retest command does not accept any targets.
The following commands are available to trigger required jobs:

/test pull-kubernetes-csi-external-provisioner-1-32-on-kubernetes-1-32

/test pull-kubernetes-csi-external-provisioner-1-33-on-kubernetes-1-33

/test pull-kubernetes-csi-external-provisioner-distributed-on-kubernetes-1-26

/test pull-kubernetes-csi-external-provisioner-unit

The following commands are available to trigger optional jobs:

/test pull-kubernetes-csi-external-provisioner-1-32-on-kubernetes-master

/test pull-kubernetes-csi-external-provisioner-1-33-on-kubernetes-master

/test pull-kubernetes-csi-external-provisioner-1-34-on-kubernetes-1-34

/test pull-kubernetes-csi-external-provisioner-1-34-on-kubernetes-master

/test pull-kubernetes-csi-external-provisioner-alpha-1-33-on-kubernetes-1-33

/test pull-kubernetes-csi-external-provisioner-canary

/test pull-kubernetes-csi-external-provisioner-distributed-on-kubernetes-master

Use /test all to run the following jobs that were automatically triggered:

pull-kubernetes-csi-external-provisioner-1-32-on-kubernetes-1-32

pull-kubernetes-csi-external-provisioner-1-33-on-kubernetes-1-33

pull-kubernetes-csi-external-provisioner-1-34-on-kubernetes-1-34

pull-kubernetes-csi-external-provisioner-distributed-on-kubernetes-1-26

pull-kubernetes-csi-external-provisioner-unit

Details

In response to this:

/retest pull-kubernetes-csi-external-provisioner-unit

kind failures should have been addressed with kubernetes/kubernetes#135575

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.

[nixpanic]

/test pull-kubernetes-csi-external-provisioner-unit

[nixpanic]

kind failures should have been addressed with kubernetes/kubernetes#135575

It seems release-tools/prow.sh uses Kubernetes v1.22.0, which isn't supported anymore, and hence not fixed. Updating the Kubernetes version in prow.sh should fix the issue.

[gnufied]

hmm, the unit test job still failed with:

 template parsing error: template: :1:19: executing "" at <.NetworkSettings.IPAddress>: map has no entry for key 
"IPAddress" 

[nixpanic]

hmm, the unit test job still failed with:

 template parsing error: template: :1:19: executing "" at <.NetworkSettings.IPAddress>: map has no entry for key 
"IPAddress" 

Yes, #1455 is not merged yet. The unit test does not have a Kubernetes version in its job yaml. It clones k/k v1.22.0:

Mon Dec  8 13:10:59 UTC 2025 go1.25.5 /home/prow/go/pkg/csiprow.8C4SPxxeru/src$ git clone --single-branch --branch v1.22.0 https://github.com/kubernetes/kubernetes /home/prow/go/pkg/csiprow.8C4SPxxeru/src/kubernetes

(from https://prow.k8s.io/view/gs/kubernetes-ci-logs/pr-logs/pull/kubernetes-csi_external-provisioner/1440/pull-kubernetes-csi-external-provisioner-unit/1998009125761454080 line 299)

[nixpanic]

/test pull-kubernetes-csi-external-provisioner-unit