Posted on January 2, 2015 by

Configuration in the Environment

Moving Fast published this article, regarding the danger of using the environment to store secrets. I think that every time is a good time to re-evaluate design choices with security implications. So that’s what I’m doing here.

My previous post focused specifically on the security implications of storing keys in your code repository. This was a particularly harmful situation with a client project I had joined. But as I think about it a little more, security isn’t the reason I use the environment to store configuration. Security is simply a byproduct. The reasons I use the environment in my company are:

1. When bringing up a new contractor or employee, I simply generate an IAM role and a key to our internal API. I plug those into the “Developer” environment IDE config file, and the new developer is up and running.

2. It’s easy to move developers between environments. We are writing V2 of our internal API as I write this. Its really quick to change your environment to build features in V2, or fix bugs in V1.

3. It felt much quicker to have a config.py pull from the environment than to parse command line parameters for our large number of configuration options or to add a dependency for an ini parser.

Reading this short list, there is really nothing here that forces us to use the environment. A config file would be just fine. Maybe I should think about that.

What concerns should I examine?

My application servers have 3 user accounts: nobody, alembic deploy user, root.

That’s it. Access to any one of those three accounts would give an attacker access to our secret keys and database. It wouldn’t matter if the configuration values were in the environment or a file. An attacker could read secrets from disk or from memory. So I don’t really gain or lose anything from using the environment instead of a config file.

My application starts up with an environment set, and reads the values from the environment into config variables.

Not only could this be done with a config file, that’s what is actually happening. The environment parameters are still stored on disk. When the server reboots, it reads the file, sets up the environment, and launches the application. So the “environment” part is simply a mirror of the setup on the developer’s system to keep production and development code consistent. So I may have the downside of both designs from a security perspective.

Very low probability of adding new config options.

When we do add a new environment config, it’s ok that it isn’t an automated process. It doesn’t happen frequently so having to redeploy our configuration manually isn’t a problem.

What do I gain from using the environment?

I don’t run the risk of a developer accidentally checking in their config file. However, if that did happen I would only have to reset their IAM credentials and internal API key.

What do I gain from using a config file?

I may only be gaining “not using the environment”. I think a successful attack on our system would happen regardless of how we stored our secrets.

Conclusions

Well I’m not sure. The Moving Fase article helped me, because we aren’t cleaning up the application environment after setting the config variables. So that is a security enhancement I will make. Other than that, I don’t think changing from the environment to a config file would give much benefit in a security or functionality sense.