Possibly there is no one good answer to this. It seems that you need to store this data somewhere safe, as it will be needed for disaster recovery purposes one day. This applies equally to properties files and scripts that set environment variables.

• With the source code (in SVN/GIT etc) is a really bad idea, as this data will contain production database passwords and the like.
• Your corporate nightly backup may be sufficient, but it is unlikely to keep a readily-accessible history of change.
• The data needs to be versioned separately to the consuming software. In our current system, a change of configuration leads to a new application build, and this is just plain wrong.

We are currently looking at solutions to this problem, and are leaning towards a code repository with restricted access. This repository would contain cofiguration data only. Do others have experiences to share?

In examining problems and possible solutions, it helps me to use a method popularized by Jeff Atwood: If God were to create a way to store sensitive configuration information, how would he do it?

Well, he would know who needs configuration information and only give it to those people, and the information would never be able to be accessed by anyone else.

The first part should already be taken care of: your source control system should be authenticating users. And this approach is also given validity according to #10 in Troy Hunt’s 10 Commandments of Source Control, “dependencies need to be in source control”.

But how to keep it secure if it is leaked? Well, it doesn’t need to be stored there in plain text! Use encryption. In .NET, there are steps you can take to encrypt connection string data in your config files. You would have to find the equivalent methods to do so with your particular technology of choice.

Many people criticize storing configuration in regular files together with your source code but in my experience, this is actually a pretty good solution:

• Simple to implement in any language. In many, you get support for complex configuration files out of the box. E.g. in the case of Java with Spring Boot, you get YAML support which can express any tree-like structure, and it’s easy to have separate configuration files for different environments as well as a baseline config from which environment-specific files can inherit.
• Configuration is needed to run your software, and changes to code often require configuration settings to be added/modified, so it’s natural to keep configuration and code together.
• Storing configuration with the source gives you all benefits of source control, like knowing who modified which setting and when or being able to check configs during a regular code review.
• Unless you work for the CIA, the security argument seems overblown to me. So your database password is stored in a file on the machine where your app runs. Well, if someone get get access to the machine with your app, you’re probably in a lot of trouble already – they can e.g. take down your app and start their own app in its place on the same port. In such a scenario, having access to the DB password might not be such a big issue. Unless all your connections are fully encrypted, having access to your machine, they can sniff much of the interesting data from network interfaces anyway.
• You can use a tool such as Hiera to have a textual configuration file but not store passwords or other sensitive data inside it.

So, for many cases, textual configuration stored in source control together with the code is a good start.

If you are into distributed systems or want to be able to hot-swap your configuration without redeploying your applications, you may find a solution based around a configuration server better. Spring Cloud has support for such mechanisms, and the backend serving configurations can be a git repository or Eureka. You can also roll your own using e.g. Zookeeper. Any of these approaches will make it easier to manage consistent configurations on many servers to update configurations without having to rebuild and redeploy your software. This comes at a cost of course, which is learning the config server and how to use it from your applications as well as yet another system to deploy and maintain.

We are battling the same problem where I work. Right now all of our configurations are file-based and source controlled with the individual applications that use them. This leads to duplication and to the developers having access to production/qa passwords instead of just development.

That said I think we’ve come up with a good solution going forward.
We are moving our config files to a separate git repo (labeled the config repo). We then set up a spring-cloud-config(java) server which simply serves the files from the config repo based on the profiles passed to it. This is great for Java applications which can use the client and download them at startup time. For our PHP/non-java apps we will pull down the file directly. (Not ideal). In the future we may write something that lets the PHP application download the configs on it’s own and cache them somewhere, but it isn’t high priority for the first run. I think of this solution as config-as-a-service which doesn’t explicitly violate the 12 factor apps recommendations.

I believe zookeeper can be used for the same thing(I saw a setup with kubernetes+zookeeper) so I’m not quite sure why that answer got a -1 above.

Links:

https://spring.io/guides/gs/centralized-configuration/

https://cloud.spring.io/spring-cloud-config/

Instead of storing the whole configuration in one file, store it in several files.

• Have a configuration directory. All files there are interpreted as configuration files, except maybe README*.
• All file names are sorted alphabetically, and the files are loaded in that order. This is why files in such cases often start with a digit or two: 01-logging.json. 02-database.json, etc.
• Data from all the files are loaded into the same configuration structure available to the application. This is how several files can complement each others’ settings, and even override them in a predictable way.
• Only store in the VCS the config files with safe-to-see values, or default values. Add the config files with secrets during deployment, or, better yet, use an authenticated secrets storage service.

On your nearest Linux box, take a look at /etc/sudoers.d or /etc/nginx/conf.d. It shows the same pattern.

Secrets management is a different beast. You can manage them as a manual step while you’re small. You can use things like Zookeeper. You can even check the secrets into a VCS in encrypted form, and decrypt them as a deployment step. A number of other options exists.

(Also, an opinion piece: JSON is not a good config file format, because it does not allow comments; comments are crucial. TOML, YAML, and even INI formats are better in practical use.)

I think your options are somewhat defined by the OS you are deploying to

I would suggest, yes put the values in source control. BUT only the ‘dev’ versions. You want your source code to compile AND work! not include extra secret steps

Your build and deploy process should then swap these values out per environment during deployment. (octopus has this kind of model)

Apache zookeeper gives wonderful options to store the application configurations for distributed systems. Changes made at zookeeper can be captured and processed by having a curator or zookeeper listener at the application end.