Storing Your Secrets in Azure Websites App Settings


Guest post by Dave White


As more applications move to the cloud, companies are faced with a few new challenges:

  • Azure web applications are frequently managed via portals by IT Professionals and not developers
  • IT Professionals may not have access to the source code to make configuration changes and arguably they shouldn’t need access
  • Applications are making greater use of secured web services provided by 3rd parties and this usually requires secret keys/access codes or account credentials
  • An organizations production API keys and account credentials should be tightly controlled

Because of these new demands, Azure Websites provide a mechanism to store our secret keys in Azure and Azure will take care of inserting them into the running application.

Where to Find the Website Applications Settings

Microsoft has two portals for managing your Azure assets. The old portal at http://manage.windowsazure.com and the new portal at http://portal.azure.com.

Old Portal

On the old portal, go to the websites (the globe) on the left hand navigation, select that and then you’ll see a list of your provisioned Azure Websites. Select the one you’d like to manage and go to the CONFIGURE tab and scroll down to the App Settings section.

image 
Image 1 – Original Portal (http://manage.windowsazure.com)

New Portal

On the new Portal, hit the BROWSE button on the left hand navigation and either find your web site in the Recent list, or go down to the Websites and find the web site you’d like to manage in the list provide. Once you have the website blade open

image 
Image 2 – Web Site Blade on new Portal (http://portal.azure.com)

image 
Image 3 – Web Site – All Settings Blade on new Portal

image 
Image 4 – Site Settings Blade on new Portal

AppSettings and Why We Want to Store Them in Azure

As a web site developer, we have historically stored all of our application settings in a section of the web.config file. This section is called <appSettings> and contains key/value pair entries in the <add key="" value=""/> element. Here is an example of one of my appSettings sections.

image
Image 5 – appSettings section example

As applications become more inter-connected with secured, 3rd party web services such as Stripe, a payment processing service, or SendGrid, an Email Infrastructure as a Service provider, the number of API keys and accounts with credentials in your web.config file will grow. The web.config file has historically been managed by developers and place into source control systems. This creates the problem of keeping these highly sensitive passwords and API keys private. Normally, many people have access (to read at a minimum) the files in source control, and if your production keys are available to many people, this increases the likelihood of abuse. It is also common for an organization to separate the function of managing these vendor accounts from the development of the application. This means that developers will not be allowed to know the production API keys and credentials.

There are also other benefits to having the appSettings set on the portal. Looking at the <add key="owin:appStartup"/> setting in the web.config above, we can set this once for the production site, and set it once for the test or demo sites, and we don’t need to worry about web.config transforms doing that work for us.

Managing Application Setting Key/Value Pairs

The really cool thing about the Azure Websites App Setting feature is that it allows you to put all of these values in your web.config so that developer local environments can use them and run, but when the site is published to Azure, the values in the web.config are transparently over-written by Azure on a per-site basis. This allows the organization to develop the application with relatively low-friction using test accounts in the web.config and quickly and easily set the production keys on the production versions of the site. In this scenario, all management of the production keys is separated from the development and publishing mechanism of the web application.

Adding a Setting

Adding a setting is as easy as typing in the Key name and the value. First, enter the key name.

image 
Image 6 – Empty App Settings slot

In this case, we will modify/set the StripeApiKey setting.

image
Image 7 – New App Settings value

Voila! Our new production Stripe API key (which is part of a pair of keys that control access to the Stripe API) has now been set. Regardless of what is in the web.config file, the site will now use the value set in Azure as the value in the application. We can quickly use Glimpse to see our server side configuration and confirm that this value is being used by the application.

image 
Image 8 – App Setting value validation with Glimpse

You can also add values to the application that are not in the web.config. Azure will always inject (and replace if already present via the web.config file) these key/value pairs into your app settings.

Delete a Setting

It is just as easy to delete a settings key. All you need to do is right-click on the entry and Delete! If there is a default value in the web.config file, it will now be used.

image
Image 9 – Right-click to delete a settings key/value pair

Don’t Forget to Save

Make sure that you use the Save button at the top of the Site Settings blade. If you don’t, you’re changes will not be persisted.

image 
Image 10 – Save Your Changes

Final Thoughts

Azure Site Settings is a quick and easy way to provide basic security and management of your application secrets. It can also be used to create and manage site specific app settings. Using this technique, organizations can ensure that their production keys and credentials are available to the IT Professionals that manage their sites via the tools they will be most familiar with. Organizations can also ensure that these secrets are known and managed by as few people as possible and can easily be changed in the event that a team member leaves the organization.

If you’ve got an Azure Website already running somewhere, go give it a try! It’s super easy and can be undone very quickly.


Dave White

image001 Dave White is a Principle Consultant for Depth Consulting. He is also a Microsoft MVP (in Application Lifecycle Management). He specializes in Lean/Kanban and Agile methodologies (frequently implemented on Team Foundation Server) as well as Microsoft development technologies (C#, HTML, CSS, JavaScript, ASP.NET MVC). He is the Program Director for the KCP Program at LeanKanban University and a frequent speaker for the Calgary .NET User Group. Dave blogs at http://www.agileramblings.com and you can find him on Twitter or LinkedIn.

Comments (4)

  1. Jaans says:

    Thanks for the very useful post! How can I do this for web.config of virtual directory applications? (E.g. http://i.imgur.com/3zTThFq.png)

  2. Dave White - canada says:

    Hello Jaans,

    Thanks for reading the article and that's a great question.

    When you have a virtual directory app, the web.config from the virtual directory app are merged with the root application web.config, which includes the appSettings section. So any app setting that is in the virtual directory applications web.config file can be overridden in the same manner as laid out in the article.

    This does present a problem that if you have, for example, two StripeApiKey values and you want to override them separately, you’ll need to name them differently in the two web.config files. Also, any app settings that are set in Azure are shared by all of those configurations, so you’ll have to make sure you’re not overwriting settings inadvertently.

    Hope that answers your question! Please let me know if I’ve missed something.

  3. mart02 says:

    Two questions:

    1- how can a webjob exe read these properties?

    2- Isn't Azure HSM the right place to store them? If yes, what would be the simplest usage example in this scenario?

  4. Shankar says:

    Can you please tell me how to achieve the same in Webjobs and App.Config file?

Skip to main content