Support identity-based connections to Storage (Managed Identity for Azure, VsCode Azure login for VsCode)
mdddev opened this issue · comments
Hello,
I am using the VS code extension of DFM. Since version 2.7.0 DF supports identity-based connections to the underlying storage provider. In my case I am using an Azure Storage account.
Please note: This storage account is configured to disable storage account key access to improve security.
I have granted the function app's MSI the blob, queue, and table contributor roles and this works fine. I also granted myself the same RBAC permissions. But now I cannot use the VS code extension because the connect dialog expects either a storage or SQL connection string and thus does not use my AAD identity for connecting.
Is there a workaround for this or am I simply doing something wrong?
Any help with this is greatly appreciated.
@mdddev , I can only confirm that this scenario is not supported by now.
Durable Functions extension itself only supports identity-based connections in preview, as of today.
We can think of making it work for DfMon in standalone or injected mode in near future. Of course, for that your DfMon instance would need to be deployed into Azure.
As for DfMon VsCode ext, enabling identity-based auth will be hard. Most requests towards storage account are done by DfMon's backend, which is run as a separate process. That process doesn't know about your identity. And plus, sometimes it uses storage SDK directly and sometimes Durable Functions SDK. At least, the latter doesn't support this auth type when outside of Azure.
Thanks @scale-tone for providing that info! Though, afaik, the identity-aware DF extension itself is not in preview, the func host's capability to connect to AzureWebJobsStorage via MSI is. I am using the TaskHub with another storage account to have a clear separation of concerns.
Regarding standalone/injected mode, would that ultimately be implemented with user-delegated permissions being passed onto the storage provider?
Kind regards
Checked it more thoroughly, and it seems that it is feasible even for VsCode ext. At least, looks less difficult to implement, than I first thought. Backend process should be able to pick up your local Azure login (the one that comes from VsCode and/or VStudio and/or Azure CLI) and produce tokens out of it.
Regarding standalone/injected mode, would that ultimately be implemented with user-delegated permissions being passed onto the storage provider?
No, the idea is to use Managed Identity, and to communicate with the Storage on behalf of it. Propagating user (human) identity from client side through all the layers down to Storage would be very hard, yet wouldn't have much sense to do. If you're looking for a way to restrict the list of accessible Task Hubs, then DfMon has a setting for that.
Understood and thank you very much for following up on this! Would an Identity-capable VS code extension be something of interest (also for others)?
That is so awesome thank you! I will try this as soon as I am Infront of my PC again and will report back here.
I have disabled account key authentication on the underlying storage account again. The DFMon vs code extension now successfully connects to the TaskHubs when I'm logged into my Azure account. This works! Thanks again for your effort, this is much appreciated!