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 https://manage.windowsazure.com and the new portal at https://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 1 – Original Portal ( https://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 2 – Web Site Blade on new Portal ( https://portal.azure.com )
Image 3 – Web Site – All Settings Blade on new Portal
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 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 6 – Empty App Settings slot
In this case, we will modify/set the StripeApiKey setting.
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 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 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 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
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 https://www.agileramblings.com and you can find him on Twitter or LinkedIn.