Late binding support in workload identity feature

[jack4it]

Is your feature request related to a problem?/Why is this needed

Today's workload identity support seems to directly use the service account and one set of tenant id / client id bound to the controller/node-daemon. That makes it difficult to support multiple storage accounts that reside in different AAD tenants

Describe the solution you'd like in detail

Add logic to instead use a service account defined in a storage class and fetch token to use for that particular class. Then we could have multi storage classes defined for different storage accounts from different places that are governed by different set of identities

Describe alternatives you've considered

We fall back to account key for now; otherwise, we'd have to install a driver instance per storage account...

Additional context

[andyzhangx]

@jack4it are you using the open source csi driver following this guide? https://github.com/kubernetes-sigs/azurefile-csi-driver/blob/master/docs/workload-identity-deploy-csi-driver.md

[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