

Securing application configuration, while still getting shit done - ukd1
https://blog.rainforestqa.com/2013-11-15-securing-application-configuration-while-still-getting-shit-done/

======
heavenlyhash
have you seen the git smudge and clean filters? they provide a way to perform
scripts like this automatically on commit and checkout.

~~~
agwa
I'll put in a plug for my project, git-crypt, which implements transparent
file encryption in git using smudge/clean filters:

[https://www.agwa.name/projects/git-
crypt/](https://www.agwa.name/projects/git-crypt/)

Be careful with some of the other git encryption projects out there - most of
them get the cryptography wrong, by using either ECB mode or CBC mode with a
fixed IV.

~~~
ukd1
This looks cool, the only thing I don't like is that it uses (from what I
understand) a single key, not one per developer. Is that planned at all?

~~~
agwa
Yes, it is planned. I have most of the design figured out and just need to
work out a few issues with revoking a developer's access. You're the first
person to ask specifically about this feature, which is good motivation to
take it off the back burner :-).

In the meantime, you can accomplish this by storing the git-crypt key in the
repository, but encrypted using GPG with multiple recipients (much like your
approach). Then you wrap `git-crypt init` in a script that first decrypts the
key using GPG before feeding it to `git-crypt init`. To add a new developer,
you just re-encrypt the git-crypt key with an additional recipient.

------
teraflop
I don't entirely understand this:

> We add the sensitive environments to .gitignore; for us this is
> production.txt, qa.txt and staging.txt. These are never committed.

> We get a history of changes in git (though it’s way more of a pain to use as
> you have to decrypt different versions)

So you have a history of changes, but only for the dev environment? Seems like
that wouldn't be terribly useful, but maybe I'm missing something.

~~~
ukd1
We have the history of changes, but not diff-able. private/env/production.txt
is not in git, however private/env/production.txt.asc is. It would be a pain
to go through the diffs, but possible. Our production config has only been
updated 35 times (this includes non-config updates like adding new keys).

------
tobyjsullivan
We do this as well. I'd recommend setting it up for all new projects as
quickly as possible to avoid having sensitive configurations in your
repository history.

For my personal projects, it enables me to host my projects on public github
repos, including configuration files, which was traditionally a pain point.

------
EGreg
In our framework we simply have a "local" subdirectory in each app which is
not checked into version control. There, we keep local environment config
including db credentials, facebook app and other api credentials, local
pathnames etc.

Solved.

~~~
ukd1
This doesn't meet the principle of least privilege; developers don't need
production access, do they?

~~~
EGreg
How do you know? You seem to be attacking a straw man. The developers dont
need to have production access.

------
hamburglar
I saw an interesting approach to this described in a blog comment a while
back. I've been pondering it ever since: [http://ejohn.org/blog/keeping-
passwords-in-source-control/#c...](http://ejohn.org/blog/keeping-passwords-in-
source-control/#comment-393229)

edit: looks like the #comment anchor doesn't expand the comment section
automatically. Search for the comment by "ntnt"

~~~
ukd1
Interesting, resig's approach doesn't work with continuous deployment, unless
you want to decrypt stuff each build (which would be less secure). Ntnt's
solution sounds awesome but imho over kill - a whole extra server?

~~~
hamburglar
Personally, I'd happily deploy an extra server or two (redundancy) to keep
from having credentials laying around unencrypted on production machines.

~~~
ukd1
This is dumb. If they need a secret, they request them using another key.
Therefore they have access to all the secrets they would have needed anyway.
What does this gain? It adds a ton of complexity and a major failure point.

~~~
hamburglar
The interesting part to me is leveraging the ssh agent. Yes, the secrets are
all behind yet another key, but it happens to be a key that doesn't leave your
local machine even when it's being used to get access to a remote secret, plus
it's a key that you likely already have set up (and hopefully secured) for ssh
access.

