You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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
The text was updated successfully, but these errors were encountered: