Skip to content

Configuration Management

Configuration concerns addressed here are scoped to only managing and maintaining credential sets and other secret information, and usage of that secret information within source control and .NET projects. We do NOT address delivery of configuration settings to different environments in this documentation, although below some tool sets are recommend for handling that.

The following are goals of proper configuration for an application: * Minimal developer ramp up * Minimal redundancy of secret information storage * Ease of discoverability and access of configuration values * Automation of configuration value replacement wherever possible.

Secure Credential Storage

You MUST store any/all sets of credentials, or other files that would be used for configuration for all environments, in a secure manner. An example of this would be a connection string, a shared secret key for an API Secret, a simple remote desktop username/password, or the password to an encrypted zip file or exported SSL Certificate.

Credentials SHOULD be properly labeled as Dev/QA/Prod categories, and SHOULD appropriately describe the system they are for. Dev/QA/Prod versions of the same credential SHOULD* all be labeled the same but be properly tagged under the appropriate Dev/QA Category.

Source Control

Given that our DevOps instance is a private and access-controlled environment, it is generally acceptable to store secure values within source control. Open source or non-private repository projects MUST NOT contain any secret information, passwords, keys or certificates.

If a previously protected project to a non-controlled environment, any secure values stored within source control MUST be invalidated and replaced with values not in source control. It is not sufficient to simply add another commit removing them: they are forever available in git history.

Class Configuration

Any classes that require configuration SHOULD declare this configuration need through constructor arguments and SHOULD NOT access the configuration wrapper directly.

Good:

public class MyCoolApiClient
{
    public MyCoolApiClient(string apiKey) // GOOD!
    {
        // do stuff with it
    }
}

Bad:

public class MyCoolApiClient
{
    public MyCoolApiClient(IConfiguration config)
    {
        var apiKey = config.ApiKey; // BAD!
    }
}

ConfigurationManager should not be used directly within classes.

Reaching out to the IConfiguration or ConfigurationManager class makes the object hard to test and hard to use in different contexts.

Back to top