How to store production secrets in an ASP.NET Core 2.0 using environment variables?

Question

From what I have read here, the recommendation is to use the secret manager to store secrets during development and then use environment variables when you deploy to IIS. I am not quite sure what is the best way to go about this - I need to be able to set the same variable to different values in different IIS applications so a system wide environment variable setting is not going to work.

I understand that I can set variables for the application in web.config but VS overwrites web.config on the server even if there is no web.conifg in the project when you do a web deploy. I know it may not be good practice to use web deploy to deploy to production but we want to do it for staging environments etc.

Is there a way to stop web deploy from overwriting web.config if it already exists on the target site?

Answer 1

Web.config is not used by ASP.NET Core. It's added as part of publishing for compatibility with hosting in IIS only. It's not intended for you to modify or use in any meaningful way.

The built in options for config providers in ASP.NET Core are: JSON, command-line arguments, User Secrets, environment variables and Azure Key Valult. However, User Secrets is only for development, and command-line arguments are difficult to utilize when hosting in IIS. (Technically, you can actually modify the Web.config to add command-line arguments, but as mentioned, that'll be overwritten on the next publish, so it's not the most tenable approach.)

Of the remaining choices of JSON, environment variables, and Azure Key Vault, only Azure Key Vault supports encryption. You can utilize Azure Key Vault whether you're actually hosting in Azure or not, but it's not free. It's not really expensive either, though, so it might be worth looking into.

JSON is probably the worst option, security-wise, mostly because it requires you to actually store your secrets in your source control, which is (or should be) a non-starter. Environment variables, while not encrypted, can be protected. However, it's difficult (though technically not impossible) to run multiple apps on the same server if they each require different secrets for the same environment variables. You can technically set environment variables at a user-level, and then you can also assign an app pool to run as a specific user. That's a lot of setup though.

That said, it's also entirely possible to create your own config providers, which means you can technically use whatever you like. For example, you can write a SQL Server config provider and then store your credentials there. You'd still need to config the connection string somewhere, but perhaps you could use the same connection string for the config for all the sites.

Answer 2

• web.config cannot be used for secrets as it's a non-encrypted plain text file

• any other file config sources (like appsettings.json) that could be added via new Configuration API cannot be used until they are not encrypted.

• it is OK to use environment variables, but only if you can guarantee that it's not possible to do a snapshot of env variables on prod machine. Look into Environment Variables Considered Harmful for Your Secrets for more details about this risk.

• if you are hosting on Azure, look into Azure Key Vault

• there are a lot of tools/services, like Hashicorp Vault that helps to deal with sensitive data