Azure-functions-core-tools: local.settings.json in .gitignore

[shladdergoo]

What is the thinking behind local.settings.json being added to .gitignore for new function projects by default? I realize that this file should not be published to Azure (or will be ignored if it is) but unless it is added to git we lose local application settings between team members as we collaborate on functions.

Can a suggest it is no longer ignored?

[ankitkumarr]

local.settings.json is a way to replicate your functions' app settings in the local machine. These settings may contain application secrets such as storage key, connection strings or your local machine specific settings. From my understanding, in most cases, you may not want to share or publish such local configuration. So, it makes sense to me to be careful/defensive by default.

Would love to hear @ahmelsayed's thoughts on this.

[shladdergoo]

Thanks for the feedback. I think the potential sensitivity of application settings is a general theme in software development and not one that needs special consideration here.

To give the simplest example I can to illustrate my point:

A new developer joins our team and she clones and builds one of our function project repos but she can't run the function because she's missing the local settings. This doesn't feel right.

[ahmelsayed]

A new developer joins our team and she clones and builds one of our function project repos but she can't run the function because she's missing the local settings. This doesn't feel right.

While this is inconvenient, it's the "right" work flow. You shouldn't be committing secrets (passwords, connection strings, certs, API keys, etc) in your source control. This presents the problem of how to run the project when you clone the repo.

The current solution is to have some other mechanism you trust of sharing these secrets between machines. I realize this is handwavy and doesn't present a concrete solution, but it's the current state. One option is to have all the settings defined on a function app in azure, then have the new developer run func azure functionapp fetch-app-settings {function-app-name} and that will download all the needed settings. That's the only automated way from the cli currently.

We're working on adding support for reading those settings from KeyVault. Once that's in, we can allow the keyvault instance name to be defined in your host.json and then the runtime will be able to fetch all the settings from there directly. That way you can just share a keyvault with Azure IAM access across your team and manage these secrets securely. I opened https://github.com/Azure/azure-functions-core-tools/issues/933 to track making the integration better from the core-tools once the runtime has the feature.

[benbelow]

@shladdergoo - I've recently set up a functions v2 project with the expectation of checking it in with non-secure settings, and having user secrets be our way of specifying secure settings locally while able to share others in git.

User secrets don't appear to be supported implicitly via the functions framework, but it's possible to add them to the provided IConfiguration by following the process described in this blog post: http://marcelegger.net/azure-functions-v2-keyvault-and-iconfiguration

[ElanHasson]

I also disagree with this behavior.

Having UseDevelopmentStorage=true in a local.settings.json is not a security risk.

Once you introduce secrets to the file, that is on you.

It's a poor developer experience to have to reproduce a config file (that can be large) or pull it from somewhere else.

One should be able to clone + run assuming they have all external dependencies (storage emulator, sql server, etc).

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.