How to store passwords in environment variables (and remove them from version control)?

Question

I’m migrating from a local tfs to a private git (probably bitbucket). Today I simply encrypt webconfig, now I will have to take my sensitive data out of version control (Connection string, passwords, etc).

How do you do it? Environment variables?

Since the answer is probably yes, every time you need to add or edit a key, I go to the infra-man and it adds "in hand"?

What about the organization of these variables? One variable for each key? At user level? Must I encrypt in some way?

In case I use Enkins, the deploy is automated. But I’m studying improvements in the process. I believe that the permissions of Jenkins do not allow changing environment variables, so the question of the guy below.

I’m also intrigued on how Azure create the variables/settings, How does Azure do to change the veritable environment by site/app? Could (should) simulate this in my systems as well?

Answer 1

How do you do it? Environment variables?

If you already encrypt your web.config, no need to worry about the security of information, right?

Basically, just encryption already solves the security issue, but this assuming you are using this method.

Since the answer is probably yes, every time you need to add or edit a key, I go to the infra-man and it adds "in hand"?

It’s not good practice to leave that to the sub. It is best to leave the configuration of variables within your system, using some internal form of encryption if this is the case.

What about the organization of these variables? One variable for each key? At user level? Must I encrypt in some way?

• A variable for each key;
• At the user level it is better to put in database, not in system;
• If possible, encrypt.

How Azure does to change the veritable environment by site/app?

It is not usually Azure that makes this change, but a process called Transformation of Web.config.

Note that your Visual Studio generates, in addition to Web.config, Web.Release.config and Web.Debug.config. These last two files are responsible for having the setting that transforms your Web.config in a modified file when published.

Could (should) simulate this in my systems as well?

This is simple to simulate. See the following answers where I explain this:

• Different connectionstring for different builds
• How not to publish an Asp.net mvc configuration file
• How to configure Web.config in Cordova project?