Managing User Secrets

Description

In this episode, Robert is joined by Andrew Cheung and Alicia Chan, who show how Visual Studio can help you stop storing sensitive data like connection strings and other user secrets in your code. They show how to store secrets locally in json or XML files and how to store them in Azure Key Vault.

Secrets management is currently for .NET Core projects. Support for WinForms and other .NET Framework projects is coming. Azure Key Vaults and Connected Services is currently available for ASP.NET and ASP.NET Core projects.

Hi I am using VS 15.8.1 community edition. I have setup the key vault as mentioned in the video and created asp.net core application. I do not see any squiggly line to select for the InstrumentationKey and hence be able to select Azure Key vault. I tried to highlight and right click and options there also.

I'd love to see this feature being used in the build process for desktop apps. The build server needs to have access of private keys for the copy protection system to work. But we definitely do not want to commit these secrets in our source.

I currently use appSettings to store connection strings. Having the appSettings.Development.json and appSettings.Staging.json makes it easy to store different connection strings for Dev, Test, and Prod environments. How would I replicate this same functionality using Azure Key vault?

Maybe adjust the video title to "Managing User Secrets with Azure Key Vault". From the title I thought this was more generalized and going to cover a few different methods of managing user secret information (web.config, app.config, config encryption for sections, windows data protection api, et cetera). At work, we develop an enterprise intranet application for banks where Azure is not an option, so we have to use other methods of securing information.

The release timeframe for the right-click menu was covered, but I think those who may not have been so intently focused might have missed it because it was very brief, but it will come in a future release is what I gathered.

Good video though. We use Azure for DevTest heavily - using user secrets for some of that might be applicable. I thought I heard him say 3 cents per transaction though? That can get very costly!

It would be useful if you show how authentication to the vault is working. This video makes it look like magic, but then when things don't work, then what? For example on premise you would need to use security principal or certificate to authenticate to the vault. In the vault you have to add into access policies these permissions. Secondly when using secrets.json locally, when you grab a solution fresh from Git, obviously this doesn't exist locally, does this have to be created manually? How do I know all the configuration key/values I need to put in here? That appears to be magic also in this video.

@kumarAzure: The flow that we walked through in the video allows you to attach a Key Vault (new or existing) to the project. When you publish your application, you will be prompted to attach that same Key Vault to your published application.

@jkruer01:One way you can do this is to create a separate Key Vaults for your dev, test, and prod environments. You can then store the connection strings to your environments in the respective Key Vaults. The Key Vault configuration can be modified to point to the correct vault in the launchSettings.json file. Please let me know if you have any further questions!

@JockStrap: Hmm. We are showing tools that are available to manage user secrets, so this episode does fit with the overall theme of the show. On the other hand, we are primarily showing Azure Key Vault and we didn't make that clear enough. I will keep the feedback in mind for future episodes.

This video makes it look like magic, but then when things don't work, then what?

You are absolutely right. We recognize this as a problem and we intend to do better. Expect us in the future to focus more on "educating you on what is actually happening" and less on making things "look like magic" as you very well put it.