Provide documentation about encrypt/decrypt settings

[solvingj]

Keeping app settings and connection strings encrypted is a very desirable prospect, but I did not believe it was possible with Azure Apps or Functions. Also, the workflow for deploying settings is fairly undesirable and inefficient. Can you please describe how the encrypt feature works with the Azure Functions CLI, what problem it intends to solve, and what the envisioned developer workflow is?

[ahmelsayed]

The way it works in the cli is different from how it works on azure.

CLI

The CLI uses a file called local.settings.json in the root of your function app folder (sibling to host.json)
that file contains a simple name-value-pair for app settings. We mainly added encryption because the file is just there on the file system and it makes people feel more comfortable handling these files that way. Especially if they end up committing it or sharing the file by mistake. However, in terms of security on your own machine, if an attacker has access to your file system. The settings are encrypted using .NET ProtectedData APIs which I think just uses standard Windows CryptProtectData.

On Azure

The recommended way is to store your app settings through the AppSettings on the Azure portal (or through the ARM REST API)
These settings are stored encrypted in Azure and only decrypted right before running your app and injected into its process memory. It's never stored unencrypted. The encryption keys are rotated regularly.

Possible workflows

There are few workflows that you can utilize, depending on your personal preference for managing secrets, etc.
If you have a function app on Azure that you want to run locally then you'd have to download the content from the portal, extract it somewhere on your machine, then you can do func azure functionapp fetch-app-settings <functionAppName> which will grab all the app settings from your function app in Azure and store it in the file I mentioned above (local.settings.json) and then you can just do func host start and it should run all your functions just like on Azure.

You can also start from the commandline or through Visual Studio. So if you're starting from Visual Studio for example you can have a function that looks like

[FunctionName("MyQueueFunction")]
[StorageAccount("account1")]
public static async Task Run([QueueTrigger("my-queue")] string message)
{
}

The runtime would expect you to have that "account1" storage account in your environment variables or app settings with a connection string to storage.
You can add that setting to your file using func settings add account1 <connectionString> or just func settings add account1 then you should be prompted for a secure value if you don't want the secrets in your shell history.
You can always run func settings encrypt\decrypt to encrypt\decrypt the file if you wanna edit it by hand.

the only remaining hole here is publishing. Ideally you should be able to publish to azure and then set all the app settings you have locally as well in one go. I'm planning to add that to the publish command in the cli itself, though publishing through other means (VS, FTP, etc) is out of scope for the CLI and would require work else where.

Does that answer your questions?

[SteveALee]

Thats a very help answer. Manually adding secrets via the portal is not ideal.

This is a definite FAQ to be added to be added to the official documenration :)

It seems a section in the cli deocs on differences from portal would be helpful too.

[solvingj]

Indeed, perhaps copy/paste this to a wiki document.

[solvingj]

To be honest however, one of the issues I was hoping to see addressed was the fact that the AppSettings and ConnectionStrings are visible in plain text from the portal. Indeed they're encrypted at-rest, but obviously there's still an issue there.

[lindydonna]

They are visible in plain text because anyone who can manage the app can view the settings. If you can run code, you could just as easily write a script that prints the value of those settings.

Closing this issue as the original question was answered. We're working on improved documentation on the CLI in the official docs.