What to avoid
- Having a variation of an application for each environment. A single artifact should be built once and then deployed to all environments otherwise you can’t guarantee that each variation has been tested.
- Having to re-build and re-deploy the artifact if changes are required in it’s environmental configuration, for same reason as above.
- Have secrets mixed in with your non-secret environment config (or anywhere in source code for that matter).
Consider Separation of Concerns
Consider who is going to make changes to the config, both secret and non secret.
|DevelopersTesters||Responsible for the schema of the configuration:Need to know the keys NOT the values across environments|
|OperationsSecurity||Responsible for the life cycle of the configuration e.g.CRUDRenew expiring secretsEnsure securityNeed to set the values as they are the ones who create these for each environment|
Where to Store
The 12 factor app says you should have config separate from application source code. Mixing environment config in with the application source code presents some problems:
- Infrastructure team have to modify application source code to update values (or pass values to Developers)
- Resource names are potentially sensitive information that might help a hacker to gain access to systems
- Infrastructure would need to modify multiple app configs if those apps are deployed to a single service e.g. K8s cluster. Whereas if config is obtained by the service runtime this only has to be done once
|Configuration Store||Stores environment specific values for the application but does not contain sensitive informationDoes not require encryption||Access by general operations|
|Secret Store||Sensitive configuration valuesConnection stringsCertificatesAccess tokensEach application should have it’s own scope||Access restricted to elevated operational roles|
Consider how config changes get into production
By accessing the config at runtime you avoid having to rebuild and redeploy app when config changes
|Technique||Required to make config change live|
|Config store accessed at runtime e.g. Azure App Configuration accessed by SDK||App picks up while running|
|Config store accessed at build timee.g. Config file in with source code.A file for each environment e.g. appsettings.json, appsettings-dev.json, appsettings-test.json||Rebuild and redeploy the app|
|Config store accessed at deploy time e.g. Helm||Redeploy the app|
Why use config store?
- Allows config to be centrally stored so easier to debug problems and compare config across related services
- Supports hierarchies of config parameters
- Control feature availability in real-time through feature flags