On the Umbraco Cloud team we have had focus on figuring out a better way of managing and using secrets throughout our applications, other than just storing them in the web.config/app.config files of our applications.
Until recently we have been storing all secrets, like connection strings for databases, storage accounts and service busses - access tokens for various services etc. directly in our configuration files. like the following:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<appSettings>
<add key="SomeServiceUsedAuthToken" value="e2095f62-1bde-4286-8c31-3264664988a9" />
</appSettings>
<connectionStrings>
<add name="Database" connectionString="Server=tcp:thaumbracoserver.database.windows.net;Database=amazingdb;User ID=mikkelhm@thaumbracoserver;Password=123456;Trusted_Connection=False;"/>
</connectionStrings>
</configuration>
The above is fine, if you know exactly who has access to the configuration file, and the configuration file is never compromised. One of the issues you could face, is employees that has had access to the repository being resigned, or a machine being stolen/lost somewhere, or a hacker gaining access to a developer's machine. Usually the configuration will be committed into the git repository and stored there. This also means that the repository has the history about the keys, like what they were in the past, and when they have been changed. Even more, if you at some point remove the key from the configuration file, it will still be in git history (as history can't be changed!).
The solution to the problem for us has been a service provided by Azure called Key Vault. I've personally fallen in love with the service, as it provides an extra layer of security on top of your existing applications and makes sure that only the right people has access to the keys needed.
The result has been that we no longer store secrets in our configuration files, rather than that, we store pointers to where in Key Vault the real secret is stored, and then access to the real secret in Key Vault is restricted to the webapp or virtual server that needs the secret. A developer on her local machine or a non-production environment can't access the Key Vault.
Further advantage for us has also been that now that we have the secrets in a central location, then we only need to maintain them at one place, and we gained a better overview of what exactly we are using - Umbraco cloud consists of many different services, with each their own configuration files, these now just point at the same pointer in Key Vault.
Azure Key Vault
Aure Key Vault is Microsofts offering for managing keys, secrets and certificates via a managed service. I won't go into details about keys and certificates, but Ill focus on the secrets parts of the service. In general Key Vault is a key-value store, hosted on Azure, securely locked behind Azure Active Directory. The Active Directory part is the thing I've struggled the most with, but once I had that figured out, accessing the vault is simple, and best of all; there's no need for storing secrets in your web.config files any more.
This will be a series of blogposts where I'll explorer how to create and manage Key Vault, and how to integrate it into different Azure services, and of course also how to implement it into Umbraco and into an Umbraco Cloud site.