6 ms·

Securing application configuration, while still getting shit done

22 points by ukd1 13y ago

hamburglar 13y ago
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/#comment-393229 http://ejohn.org/blog/keeping-passwords-in-source-control/#c... edit: looks like the #comment anchor doesn't expand the comment section automatically. Search for the comment by "ntnt"
- ukd1 13y ago
  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 13y ago
    Personally, I'd happily deploy an extra server or two (redundancy) to keep from having credentials laying around unencrypted on production machines.
    - ukd1 13y ago
      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 13y ago
        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.
EGreg 13y ago
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 13y ago
  This doesn't meet the principle of least privilege; developers don't need production access, do they?
  - EGreg 13y ago
    How do you know? You seem to be attacking a straw man. The developers dont need to have production access.
heavenlyhash 13y ago
have you seen the git smudge and clean filters? they provide a way to perform scripts like this automatically on commit and checkout.
- ukd1 13y ago
  No, but that sounds awesome! Just looking for examples :)
  - heavenlyhash 13y ago
    Check out the email from Michael J Gruber on the git mailing list: http://git.661346.n2.nabble.com/Transparently-encrypt-repository-contents-with-GPG-td2470145.html http://git.661346.n2.nabble.com/Transparently-encrypt-reposi... There's a fairly complete example there, plus discussion. (It's worth mentioning that many of the git maintainers find this to be an odd use of the git filters feature, because it doesn't let you diff things. But of course, that's not the point.)
    - agwa 13y ago
      The first example there uses gpg, which is a very sub-optimal approach because gpg uses non-deterministic encryption. That means that git always thinks the file has changed, because every invocation of the filter produces a different output. A later example tries to fix this by using deterministic encryption with openssl instead of gpg, but it's insecure because it accomplishes the determinism by using either ECB mode or CBC mode with a fixed IV. The proper solution is to use a real deterministic encryption scheme (such as CTR mode with the nonce derived from a HMAC of the plaintext), and also use a diff filter so git diffs work. Not only does git work properly, it's actually secure too! My project, git-crypt[1], works this way. [1] https://www.agwa.name/projects/git-crypt/ https://www.agwa.name/projects/git-crypt/
      - ukd1 13y ago
        GPG is fine, if you don't decrypt and then encrypt unless you're doing an update. So, why would it matter?
tobyjsullivan 13y ago
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.
teraflop 13y ago
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 13y ago
  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).

22 points by ukd1 13y ago

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/#comment-393229 http://ejohn.org/blog/keeping-passwords-in-source-control/#c... edit: looks like the #comment anchor doesn't expand the comment section automatically. Search for the comment by "ntnt"

ukd1 13y ago
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 13y ago
  Personally, I'd happily deploy an extra server or two (redundancy) to keep from having credentials laying around unencrypted on production machines.
  - ukd1 13y ago
    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 13y ago
      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.

EGreg 13y ago

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 13y ago
This doesn't meet the principle of least privilege; developers don't need production access, do they?
- EGreg 13y ago
  How do you know? You seem to be attacking a straw man. The developers dont need to have production access.

heavenlyhash 13y ago

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

ukd1 13y ago
No, but that sounds awesome! Just looking for examples :)
- heavenlyhash 13y ago
  Check out the email from Michael J Gruber on the git mailing list: http://git.661346.n2.nabble.com/Transparently-encrypt-repository-contents-with-GPG-td2470145.html http://git.661346.n2.nabble.com/Transparently-encrypt-reposi... There's a fairly complete example there, plus discussion. (It's worth mentioning that many of the git maintainers find this to be an odd use of the git filters feature, because it doesn't let you diff things. But of course, that's not the point.)
  - agwa 13y ago
    The first example there uses gpg, which is a very sub-optimal approach because gpg uses non-deterministic encryption. That means that git always thinks the file has changed, because every invocation of the filter produces a different output. A later example tries to fix this by using deterministic encryption with openssl instead of gpg, but it's insecure because it accomplishes the determinism by using either ECB mode or CBC mode with a fixed IV. The proper solution is to use a real deterministic encryption scheme (such as CTR mode with the nonce derived from a HMAC of the plaintext), and also use a diff filter so git diffs work. Not only does git work properly, it's actually secure too! My project, git-crypt[1], works this way. [1] https://www.agwa.name/projects/git-crypt/ https://www.agwa.name/projects/git-crypt/
    - ukd1 13y ago
      GPG is fine, if you don't decrypt and then encrypt unless you're doing an update. So, why would it matter?

tobyjsullivan 13y ago

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.

teraflop 13y ago

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 13y ago
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).