Propagation of NodePublishVolumeRequest.VolumeContext to providers

[micahhausler]

Describe the solution you'd like

I was wondering if it is intentional to filter out VolumeContext (Pod .spec.volumes[].csi.volumeAttributes) parameters passed on to providers by limiting the key to:

• csi.storage.k8s.io/pod.name
• csi.storage.k8s.io/pod.namespace
• csi.storage.k8s.io/pod.uid
• csi.storage.k8s.io/serviceAccount.name
• SecretProviderClass .Spec.Parameters

Is the pod creator considered untrusted? It might be convenient for providers to have access to volumeAttributes for per-volume metadata.

[aramase]

The volume attributes are user defined apart from the default ones added by kubelet.

csi.storage.k8s.io/ephemeral:true 
csi.storage.k8s.io/pod.name:nginx-78cfc8db98-5s5rr 
csi.storage.k8s.io/pod.namespace:default 
csi.storage.k8s.io/pod.uid:9f88edc9-4b36-4405-9802-7aa621df338c 
csi.storage.k8s.io/serviceAccount.name:default 
secretProviderClass:testspc

The change should be minimal in NodePublishVolume. However we need to reconstruct these attributes in the rotation logic as rotation isn't invoked by kubelet.

secrets-store-csi-driver/pkg/rotation/reconciler.go

Lines 220 to 224 in 7f21cd3

	// Set these parameters to mimic the exact same attributes we get as part of NodePublishVolumeRequest
	parameters[csipodname] = podName
	parameters[csipodnamespace] = podNamespace
	parameters[csipoduid] = string(pod.UID)
	parameters[csipodsa] = pod.Spec.ServiceAccountName

If we explore the option of doing rotation based on the requiresRepublish and it's feasible, then we might be able to just rely solely on NodePublishVolume and pass the whole volume attributes as is to the provider.

[tam7t]

Based on some of the discussion on #585 we likely don't want plugins to rely on having this information (since some may be missing during rotation requests) but that a good start is to pass all attributes on any real request.

IMO we should do this and close it once we pass all attributes, and work on #585 toward providing more attributes in a backwards-compatible way for the rotation feature.

/assign @aramase

[k8s-triage-robot]

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

This bot triages issues and PRs 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 or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

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

/lifecycle stale

[aramase]

/remove-lifecycle stale