Managing Cloud Ready .NET App Secrets in Visual Studio

This post has been republished via RSS; it originally appeared at: Microsoft Developer Blogs.

App Dev Manager Keith Beller explores how to handle App Secrets in Visual Studio. Secrets need to be handled with care and this is the responsibility of every developer. We’ve all read those news reports of someone accidently checking a production password into source control only to find out the next day that their credit card has been maxed out. Obviously, no one wants to be “that person,” so today we are going to provide a few tips that will help you maintain your app secrets like a professional. The .Net Core documentation team has posted several excellent articles on secret management that I would encourage you to read. There is no need to rehash all the content included in the articles; instead, I’d like to highlight some of the options you may want to consider as you configure your secrets management workflow. Safe storage of app secrets in development in ASP.NET Core Azure Key Vault Configuration Provider in ASP.NET Core In summary, there are a few basic options for storing and retrieving sensitive data. How secrets are retrieved from your development and production environments is a function of your secret’s management workflow. The graphic below depicts a simplified workflow that demonstrates the most common options. The critical point here is that your workflow does not persist secrets to source control. Additionally, and for completeness, you should not store secrets in a database. Also, we’ll not discuss using Active Directory, but it may be an option if you’re team is working in a Windows context. No matter what secrets management option you select, there are general principles that should always be followed. First, development secrets should be unique and should not be shared with upper environments like QA or Prod. Next, you should limit access to production secrets to those that need to know them. Establish a rotation policy for production secrets. Finally, don’t store unencrypted secrets in production. As the workflow illustrates, if you use Active Directory in Development then you would use Active Directory in Production. This option may work well for resources like MS SQL Database. Another option is Environment Variables. If you’re working in the cloud or a hybrid environment, you can pair Secrets Manager with Azure Key Vault. When working in the cloud, this is the preferred option since Key Vault ensures production secrets remain encrypted. Environment Variables As we point out in the Protect Secrets in Development article linked above, if you decide to go the Environment Variable route please be aware that they’re generally stored in plain, unencrypted text. If the machine or process is compromised, environment variables can be accessed by untrusted parties. Additional measures to prevent disclosure of user secrets may be required, so considerations should be evaluated with your team as you decide how you’d like to set up your workflow. If you decide to proceed with this option, all you’ll need to do is set up environment variables for both your development and production environments. Then you’ll need to make sure your production variables are encrypted. Secret Manager + Azure Key Vault One feature that developers may not be aware of is something called Secrets Manager. This is available in the latest version of Visual Studio and pairs nicely with Azure Key Vault. You can access “Manage User Secrets” by right clicking the project in the Solution Explorer. The cool thing about this option is that it creates a file that is uniquely linked to your project, but is not found in the source code directory hierarchy so there is no way to accidently check secrets into source. The secrets are stored in a secrets.json file which is stored in the C:\Users\<UserProfile>\AppData\Roaming\Microsoft\UserSecrets\<Guid> directory on your development machine. Once configured, secrets can be retrieved in your application Startup.cs class via the Configuration API. From there you can pass them via injection to your ASP.Net controller or some other context. When you’re ready to release to the cloud all you have to do is make sure you’ve set up your Azure Key Vault secret with a matching name and granted access to your application. For more details see the Azure Key Vault Configuration Provider article linked above. Taking time to define a Secrets Management Workflow is relatively simple and will protect your application secrets from accidental exposure.

REMEMBER: these articles are REPUBLISHED. Your best bet to get a reply is to follow the link at the top of the post to the ORIGINAL post! BUT you're more than welcome to start discussions here:

This site uses Akismet to reduce spam. Learn how your comment data is processed.