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.
Roles
| Role | What |
|---|---|
| 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
| Storage | What | Role |
|---|---|---|
| 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
