When setting up a project to use Azure Key Vault, one currently has to create an actual key vault with keys stored in Azure just to develop an Azure Function that uses the Key Vault for its secrets.
To better facilitate and streamline development using the Key Vault, it would be super helpful if there was a Key Vault emulator that ran offline for local development purposes. This could [over]simplify some of the steps in order to defer some of the configuration complexity for later in the process at the point of deployment.
Does this belong in the Functions VS Tooling?
Azure currently injects the environment variables that provide access to a Key Vault to an executing Function (MSI_ENDPOINT and MSI_SECRET). Likewise, the VS Tooling for Functions would need to inject these same environment variables to reference the locally running KV emulator. If the MSI interface is being emulated, then maybe there's no need to muck with AzureServiceTokenProvider?
How would the KV Emulator Work?
Perhaps this could also piggy back on the secrets.json convention used for web apps? Secrets could be stored there as the local "key vault", sort of. The local emulator doesn't need to meet all the same standards, but it should be able to minimally wrap secrets (actually stored in secrets.json) and point to certificates by thumbprint and local user store name (actually stored in the local user's certificate store).
Forget all the provisioning part, just to keep it simple ... if the local developer has access to it, then the local app has access too. Also, only "GET" / "LIST" access should be implemented as read-only situations capture 98% of use cases.
References
When setting up a project to use Azure Key Vault, one currently has to create an actual key vault with keys stored in Azure just to develop an Azure Function that uses the Key Vault for its secrets.
To better facilitate and streamline development using the Key Vault, it would be super helpful if there was a Key Vault emulator that ran offline for local development purposes. This could [over]simplify some of the steps in order to defer some of the configuration complexity for later in the process at the point of deployment.
Does this belong in the Functions VS Tooling?
Azure currently injects the environment variables that provide access to a Key Vault to an executing Function (
MSI_ENDPOINTandMSI_SECRET). Likewise, the VS Tooling for Functions would need to inject these same environment variables to reference the locally running KV emulator. If the MSI interface is being emulated, then maybe there's no need to muck withAzureServiceTokenProvider?How would the KV Emulator Work?
Perhaps this could also piggy back on the
secrets.jsonconvention used for web apps? Secrets could be stored there as the local "key vault", sort of. The local emulator doesn't need to meet all the same standards, but it should be able to minimally wrap secrets (actually stored insecrets.json) and point to certificates by thumbprint and local user store name (actually stored in the local user's certificate store).Forget all the provisioning part, just to keep it simple ... if the local developer has access to it, then the local app has access too. Also, only "GET" / "LIST" access should be implemented as read-only situations capture 98% of use cases.
References