weizhi

So you will create Managed Identity(Service Principal) for each Namespace? Since every ServiceAccount would federate with a Managed Identity(Service Principal).

Got it. So only applications with ServiceAccount(federated with MSI/SP beforehand) that has the permission to create and mount storage account can trigger CSI to provision and mount volume for them....

Hi @karlschriek , I think https://kubernetes-csi.github.io/docs/token-requests.html is what we are looking for. **This feature allows CSI drivers to impersonate the pods that they mount the volumes for.** Thus we can...

> Got it. So only applications with ServiceAccount(federated with MSI/SP beforehand) that has the permission to create and mount storage account can trigger CSI to provision and mount volume for...

There are two steps for a Pod to use a volume: provisioning and mounting. For the provisioning process, actually, it's the csi driver's responsibility to interact with Azure storage API...

@pinkfloydx33 Does that implementation make sense to you?

We are gonna implement this feature, below is the specific use case, could you please take a look and see if it satisfies your requirement? Any suggestion would be helpful,...

I'm not sure whether azurefile can support wli authentication now, I think not. But at least we can use wli to get the access key, that's the plan for now....

> Sounds good. Would be better if azurefile would support wli directly 😁 That's right, it will be more efficient and safer if azurefile/blob can support wli authentication directly. But...

Abandon https://github.com/kaito-project/kaito/pull/1059 and file this one, which removed CLOUD_PROVIDER env related change according to the suggestion.