Get Your Secrets Into Source Control
| DevOps |
“Get your secrets into source control!”
That may seem like rather strange advice, but it’s exactly what we’re going to try and do. Allow me to explain!
Agile and DevOps are setting the world on fire, and there are plenty of problems that are yet to be solved. But one thing everyone can agree on is that the more stuff which is tracked in source control, the better.
However, secrets aren’t safe in source control, which means that they often live an independent existence outside of the mainstream code/commit/test/deploy workflows.
At Conjur, we’re building a simple, extensible software tool that will provide the best of both worlds: better security by moving secrets out of source control, combined with the convenience of having secrets in source control. We’re not quite ready to release the software, but we are ready to discuss (and get your feedback on) the requirements and design goals. So please read on…
The first problem that ensues when secrets are separated from source control is that it’s not even clear which secrets are needed to run an application. Once you checkout the repository, you either have to dig through the documentation (which is hopefully current), or start monkey-testing the app to figure out what’s needed to get it to work.
Once you figure out what secrets you need, you have to obtain them. You may have some already, in another directory. You may copy them over into the new project, maybe have to reformat them a little bit. It may turn out that your secret is expired, and you’re stuck hunting it down anew. You may ask a fellow team member to provide you with a secret that you don’t have; frequently these secrets are sent over insecure transport media like email and chat.
Next, the application may not be expecting the secrets to be provided by the environment. If the secrets are embedded into configuration files, it’s not even enough for you to have the secret; you have to find the right file and place the secret there. Keeping secrets in configuration files is a practice that needs to be phased out; you can read a further exposition of this point of view at 12factor.net/config. Summon works best with 12factor applications; in fact it strongly pushes in this direction. That means predictability for developers, operations and security folks.
Overall, ad-hoc secrets management is a big pain, and the only reason that anybody tolerates is that they are used to it.
Well, let’s create a better way. The new standard for secrets in code, which we’re calling Summon, has the following design:
Secrets are declared explicitly in a safe source code file that gets committed along with the rest of the project code. We’ll call it secrets.yml. secrets.yml contains the names of secrets, but not the actual values.
Secrets are injected into the application when it’s launched.
By default, secrets are obtained from the process environment. However, secrets may also be placed in files for the application to read.
Secrets are physically stored in a secure location which is not the source control repository. The specifics of secrets storage and retrieval are abstracted, so that the application code is not explicitly tied to the secrets provider. In other words, there’s a swappable secrets backend, which decouples the infrastructure code from the secrets provider.
Different secrets providers can be used in development, stage and production without having to modify the deployment artifacts (e.g. installer packages, VM images, container images).
Summon runs anywhere, it’s lightweight, it’s easy to install.
It’s simple and easy to develop new backend providers.
We’re still a few weeks away from an official release, but we are ready for you to get involved! Simply click the button below and fill out the form and we’ll let you know when Summon is ready (we promise not to spam you with marketing emails):
We look forward to solving this tough problem together with you all!