Add binding to Key Vault
Functions often need password, API keys, and connection strings to connect to other services and retrieve data. It would be great if those secrets could easily be obtained from Key Vault.
We’re pleased to announce a public preview of our Key Vault references feature, which you can learn more about here: https://azure.microsoft.com/en-us/blog/simplifying-security-for-serverless-and-web-apps-with-azure-functions-and-app-service/
There are some limitations to the initial preview, but we’re hoping to address those very soon. We’re looking forward to your feedback!
Matthew, Azure Functions team
Mahesh Nagaiah commented
We are looking forward for the General availability dates of this feature. Can you please share the same?
Brett Caswell commented
is the KeyVaultSample in the github source of Microsoft.Extensions.Configuration package a suitable workaround for this?
Is your recommendation to still use EnvironmentVariables (as stated in the last paragraph here: https://docs.microsoft.com/en-us/azure/azure-functions/functions-dotnet-class-library#environment-variables )
Chris Thompson (m1nkeh) commented
ooo, this is nice... assume it's only for functions v2.0 ?
Geek Squad Tech Support commented
Well, I must appreciate your efforts in writing blogs. They are informative. But, also keep your website updated with antivirus. For relevant help contact Geek Squad Tech Support. https://geeksquad-usa.com/
Boris Wilhelms commented
I have created a nuget package, that integrates Azure KeyVault into Azure Functions (MSI enabled, can be used with AutoResolve and AppSettings properties, etc). Feel free to test and give feedback :-)
Any news on this feature ? We're using Azure Functions v2 with MSI and accessing secrets within the function works. However, now I require those secrets to also be accessible in the trigger bindings for eventhub and servicebus connections due to security reasons. When can we expect this feature?
Looking forward to this!
Come on, 2018 and still not implemented? It makes Az Funcs useless ..
Any updates on this. We are using EventHubTrigger in Azure Functions, but it requires binding connection string into local.settings.json whereas we have all our applications migrated to KeyVault secrets. We would like to follow the same approach with Azure Functions but it doesn't seem supported for now. Can you please provide this feature as soon as possible, as already Azure Functions 2.0 (~beta) is already out and in use.
Jacque de Kock commented
Very high in demand. We often have to over complicate infrastructure to achieve this function. Cannot wait for it to be available.
Akshay Kochhar commented
Please support this
Please support at the earliest (MSI enabled function and secret Uri in trigger binding)
Steve Haeney commented
Just to echo what many are saying. Without KeyVault access directly in the bindings, you're unlikely to be able to use Azure Functions with Queues/Topics in the Enterprise.
Storing the connection string in plain text in the configuration is a no-go
Vivek Desai commented
Upvoting this request. from the Aug 2016 reply it seems this is being interpreted as a request to add Keyvault as a new binding ("when we’re ready to start adding more bindings"). What is really required to to have existing bindings resolve secrets from a Keyvault configuration source rather than looking to resolve them from json or env variables only.
The Keyvault + Managed Service Identity is an excellent combination, but without the ability of bindings like cosmosdb, storage table etc to retrieve connection strings from key vault source, it is becoming impossible to use Key vault and MSI for Azure Functions.
Tom Castiglia commented
Wow, surprised to see this is not supported yet. Hope the Azure App Service Team can respond soon with an update/ETA.
Pinging for update on this
Tom Kerkhove commented
@Tsahi Whetever you do, do not cache secrets in a persistent cache/storage outside of Key Vault :)
You can always access Key Vault directly from the Key Vault SDK, and even cache the results in Storage Tables if you like. And restrict access to it on a need-to-know basis only.
Denis Oliana commented
It would be great if there was an update: I don't think, that this is still under review, after 1.5 years ;-)
Ciaran Colgan commented
Hi - if we can't have ServiceBus Triggered Functions having built in integration with KeyVault or something that allows us to actually connect to ServiceBus without storing the ServiceBus connection string, then these are effectively useless in any kind of secure deployment. This is a real showstopper for us, it basically invalidates our use of ServiceBus.