CODEWITHSUNDEEP
iisasp.net-coretfscontinuous-integrationrelease
Heinrich
Heinrich

Reputation: 876

How to handle on sensitive configurations on a release with asp.net core?

I am seeking the best way to handle configurations in my aspnet core applications. See below my scenario.

  1. Currently I am using the TFS as a repository of code and as the orchestrator of all my release definitions that goes to a webserver with IIS

  2. I have a multitenant application and my code currently stores in the applications settings the configuration I have per client

    appsetting.Client1.json

    appsetting.Client2.json

ConnectionString is part of the variables that are stored in my appsettings.Client#.json

Now, a big problem I am seeing so far is that I am saving all configurations in my repository, and all developers have access to my PROD settings as well.(something I want to avoid, like the connectionString)

My solution so far to this problem is trying to save all sensitive configurations in the configuration variables of my IIS per client.

enter image description here

and avoid having them on the code directly and also as part of the configuration on the continuous integration process on the TFS, which should look only as an orchestrator. So the app should take every secret thing from IIS configuration. Which now take me to another doubt if I am doing the things right: I will not have the connectionString as a section anymore on my appSettings so I will not get them as I usually did configuration.GetConnectionString.

Should I need to consider a different approach with the resources I have?

Upvotes: 1

Views: 83

Answers (1)

Chris Pratt
Chris Pratt

Reputation: 239430

In development, use user secrets. It's basically just JSON config, but it's stored outside your project in your user directory. That way, there's no chance of any secrets making it into your source control. You don't need to do anything special, as user secrets config is included by default. Just right-click on your project and choose "Manage User Secrets".

In production, you can use environment variables, Azure Key Vault, etc. Basically, just as with development, you want to keep the secrets external to your project and out of your source control.

Because all these settings are external, it's also a good idea to mock them up in something like appsettings.json. For example:

{
    "ConnectionStrings": {
        "MyConnectionString": "[CONNECTION STRING]"
    }
}

Then, you actually specify the value in user secrets in development and environment variables, Azure Key Vault, etc. in production. Since appsettings.json is included first, the other config sources will override the placeholder(s) here. But, it serves to document your config, so other developers know what they need to provide.

Upvotes: 1

Related Questions