[FEATURE REQ] Managed Identities on VDI's (Virtual Desktops in Azure) cannot have their managed identity bypassed, add setting to disable

[jsquire]

Library name

Microsoft.Azure.WebJobs.Host

Please describe the feature.

This has been brought up before, but for companies that have their developers work on Azure VDI's (running in azure) the Azure VDI itself has a Managed Identity, and due to the way DefaultAzureCredential works, ManagedIdenties always take priority over every other identity including VS, VSCode, Azure CLI, etc.

This means that when you run an Azure Function locally that has things like service bus triggers, it will always run as the identity of the VDI regardless of what the developer is logged in as. This creates a scenario where developers have to have full service bus connection strings for it to run locally, which isn't ideal. Not every developer has access to go get those, we don't want to manage connection strings in local.settings, we dont want them messaging them to each other either nor do we want newly onboarded developers to have to build their local.settings. nor do we want to foster an environment where they try to check them into source control... We want developers to login to Azure CLI and be authenticated and things to run as their Azure CLI session or their logged in user (to the vdi itself)

Now with code, we solved this by modifying DefaultAzureCredential so that when running locally the managed identity is disabled so for things we programmatically control this isn't a problem. But for things in theazure function runtime, there's no way to turn this off.

We do not want code to run as the azure vdi managed identity, from an audit perspective and from a management perspective. We want it to run as the logged in user either to the VDI itself, or via azure cli. In the world we are building with Bicep, IAC, etc we want developers to clone a repo, press f5, and it works. And if we solve this problem we have that...

What I have to do right now to work around this problem is map all the vdi managed identities to have access to stuff, but that breaks the audit trail and we can't keep doing that because that audit trail doesn't tell us who was logged into that VDI when that code ran.

We need a setting that allows us to disable managed identities from DefaultAzureCredential with an environment variable, like "DefaultAzureCredential_ManagedIdentity": false

that way we can check in our local.settings.json which won't have any connection strings in it.

Or something as good or better than this idea.

Telling developers to use direct connection strings isn't really palatable in enterprise financial environments.....