Extension performs a ListKeys operation on all storage accounts your account has access to
jan-delaet opened this issue · comments
We ran into a bit of a scare earlier when we noticed that for some accounts a ListKeys operation was detected on multiple storage accounts at several of our customers. Our company does consulting for different customers and as a result those consultants have access to several different Azure tenants and subscriptions. Some of these are managed through Lighthouse, but some of them get access through the use of guest accounts invited to those tenants.
After being notified by one of the security teams about this ListKeys operation we saw that this was happening across all of this customer's subscription, and that this was happening at other customers as well. It seems like all affected storage accounts were those that have their access governed through Azure Lighthouse.
Steps to reproduce:
- Open VS Code
- Authenticate to Azure using the Azure extension (using an account that has Lighthouse managed customers)
- Open the Durable functions monitor tab
- Wait a few minutes, then navigate to the activity log of one of the storage accounts in one of these Lighthouse subscriptions
- Take note of the fact that your account did a ListKeys operation on this storage account without ever being selected in the extension
To us this seems like a security concern, or at least will continue to make security teams very nervous whenever this shows up. Would it not be more sensible for the ListKeys operation to only be triggered for an individual storage account that gets selected?
Hi @jan-delaet , thanks for raising this concern.
I can confirm that DfMon VsCode extension indeed does a ListKeys operation on Storage accounts accessible by current user - that's the way the extension discovers Task Hubs in those accounts.
Personally I do not see it as a security concern, and rather the opposite: if your security team sees that ListKeys operations succeed for someone who they should not succeed for - that's a good food for thought anyway. Remember that if DfMon is able to access these secrets, that technically means that any VsCode extension has the same amount of access (and people tend to have quite a zoo of those extensions today).
Please, feel free to disagree and elaborate on the concerns that you have about it.
Important to note, that DfMon uses storage keys as the primary (more traditional and more reliable) means of authentication, but falls back to user's Azure identity when storage keys are not accessible (e.g. when they're disabled for the storage account)
That said, we can consider making identity-based auth the default one in future versions. Or provide a configuration switch for this.
@jan-delaet , in v6.0 the tree view was completely redesigned, so that now it only searches for Task Hubs in a subscription after the user actually expands that subscription in the tree. In other words, the ListKeys operation is now explictly and intentionally initiated by the user.
Does that address your concern?
It seems that I get an error that is related to listing keys in all storage accounts. There are a bunch of storage accounts in my subscription and I have an access to only some of them. The error I get when expanding subscription:
Failed to load tree items. The client 'user@contoso.com' with object id '...' has permission to perform action
'Microsoft.Storage/storageAccounts/listKeys/action' on scope
'/subscriptions/.../resourceGroups/.../providers/Microsoft.Storage/storageAccounts/...';
however, the access is denied because of the deny assignment with name 'System deny assignment created by Azure Databricks
/subscriptions/.../resourceGroups/.../providers/Microsoft.Databricks/workspaces/...'
and Id '...' at scope '/subscriptions/.../resourceGroups/...'.
Thanks for reporting this @savbace , will try to address this scenario in next version.
As a workaround, you can always connect to a Task Hub via a plain old Storage Connection String.
@jan-delaet , in v6.0 the tree view was completely redesigned, so that now it only searches for Task Hubs in a subscription after the user actually expands that subscription in the tree. In other words, the ListKeys operation is now explictly and intentionally initiated by the user.
Does that address your concern?
Still seems a bit excessive to list all storage account keys in the expanded subscription rather than doing it on a per storage account basis (i.e. when expanding the storage account itself), but this is definitely a lot better and allows us to use this extension once again without accidentally spooking some of our customers. Thank you!
Addressed this in v6.1 by adding a new Task Hubs Discovery Mode setting. Set it to Do not use Storage Keys to prevent DfMon from doing listKeys.