Encrypt Web.Config (Web.Release.config) Transform files using aspnet_regiis

Question

I have a requirement to not store any sensitive information (e.g. usernames and passwords) in source control. We are doing a .NET 4.5 MVC app so my plan was to encrypt the web.config using the aspnet_regiis.exe and the built in functionality of ASP.NET. I have no problem getting this to work here but the issue I am having is that I would also like to encrypt the transforms (Web.Release.config, etc.) because that also contains the sensitive information. I have looked around and not seen any way to do this. Does anyone know a way to accomplish this?

Answer 1

The way I was able to make this work was by going to each machine and encrypting the web.config there with the correct connection string and then copying the newly encrypted connection string section into the appropriate web.cong transform. It is a huge pain but it works.

Answer 2

You can keep your production transform file in a secrets repository that only your ops team can access. Your CI system would reference both repos and copy the transform file from your secrets repo to your build directory and compile as you do now.

This would remove any sensitive config values from your primary repository and still allow your to leverage the transforms capabilities.

Answer 3

Try following, I have just given the example of protecting connection string. Replace the tag you want to replace using System.Configuration;

 ExeConfigurationFileMap configMap = new ExeConfigurationFileMap();
                configMap.ExeConfigFilename = modulePath + "Web.Release.config";
                System.Configuration.Configuration config = ConfigurationManager.OpenMappedExeConfiguration(configMap, ConfigurationUserLevel.None);
                System.Configuration.ConfigurationSection section = config.GetSection("connectionStrings");
                if (!section.SectionInformation.IsProtected)
                {
                                   section.SectionInformation.ProtectSection("RsaProtectedConfigurationProvider");
                    config.Save();
                }

Answer 4

There are a couple different ways of handling this depending on you're needs and the different types of access that you and your development team have to the servers.

Option 1. Check in encrypted transforms files to source control.

Create your web.config and encrypt the appsettings and connectionstrings using aspnet_regiis.exe. Then in your transform (ex. web.release.config) for each environment use the following values:

<appSettings configProtectionProvider="ProviderName" xdt:Transform="Replace">
<EncryptedData>.....</EncryptedData
</appSettings>

If you are using different providers in each environment (you should be), then you will need to do the encryption for each environment.

Problem: If you have multiple developers/projects going on, it can be easy to miss a new appsetting value and you won't know until its deployed

Option 2. Use Transforms + Token Replacement and Encrypt in place on the server

For this option you would use your traditional transforms, but replace all sensitive data with tokens, such as {{WebServicePassword}}. Token replacement is a common functionality that exists in most deployment tools. In this case you would create a variable in your deployment tool (VSTS, UrbanCode, etc..) that has the true value of {{WebServicePassword}}. You would then need to configure your deployment to do a tokenized replacement and the specific details of this would differ base don the deployment tool in question. Once the file is deployed, then run the aspnet_regiis.exe remotely on the server to encrypt the web.config file in place.

Problem: The unencrypted file will be sitting on the server for a brief moment before it is encrypted. Depending on your situation, this may or may not be an issue.

Personally I prefer option #2 as it allows you to see all of the appsettings keys and you can easily handle changes to keys (not the values) through pull requests/code reviews. When dealing with the encrypted appsettings/databaseconnections values in source control, you have no idea if the encrypted value actually contains the keys your application needs.