Support refresh of SAS token (re-reading it from KeyVault, updating the mount)

[calohmn]

Is your feature request related to a problem?/Why is this needed
When mounting a storage container using a SAS token, the recommended kind of SAS to use would be a user delegation SAS.
Because of the limited validity period of such tokens, they have to be re-created periodically. The updated token (in an updated KeyVault Secret) then needs to be applied to the blobfuse volume mount.

Currently, the only way to apply an updated SAS token seems to be to restart the pod which contains the (inline) volume for the storage container mount.
For tokens that have a short validity period (of say 1 hour), this doesn't look practical, restarting pods every hour.
It would be better for the blob CSI driver (blobfuseproxy) to support this kind of scenario, applying the updated SAS automatically.

Describe the solution you'd like in detail
Ideally, changes to the K8s secret containing the SAS token would be detected (via Kubernetes "watch"), and the corresponding mount would be updated.
As far as I've seen, such a mount update would be possible when mounting using a config file - as noted in Azure/azure-storage-fuse#1246 and Azure/azure-storage-fuse#1301 (comment).

[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

[Christian-Schmid]

/remove-lifecycle rotten We are still affected by this

[Christian-Schmid]

/remove-lifecycle rotten