Hiera, version control & encrypted backends

[Alex Harvey]

Hi all,

I'm pondering a design problem and would appreciate some advice:

A reason for externalising data in Hiera is often said to be so that configuration data can be stored in a version control system, e.g.

http://puppetlabs.com/blog/first-look-installing-and-using-hiera

Meanwhile, the reason for using an encrypted Hiera backend is so that sensitive configuration data can be stored in Hiera, e.g.

http://www.craigdunn.org/2011/10/secret-variables-in-puppet-with-hiera-and-gpg/

Thus, there is a catch: if data is too sensitive to be stored in an unencrypted Hiera backend, it is probably too sensitive to be stored in a version control system like git.

I've seen people out there have considered encrypted version control systems, others have said sensitive configuration data shouldn't be stored at all, and so on - I can't find much discussion of the problem itself though.

After thinking about it for a while, the best I could come up with was supposing there ought to be a way of partially encrypting the Hiera backend, and perhaps dealing with it using a separate level in the hierarchy.

I note the Raziel project along these lines by Jens Bräuer:

https://github.com/jbraeuer/raziel/
http://bit.ly/raziel-slides

Is this more of an open problem or has the community come up with a best practice recommendation here?

Kind regards,

Alex

[Matthew Kennedy]

We use hiera-eyaml... This let's us selectively encrypt keys (passwords) and let everything else remain plaintext.

We use git and have very little concern as long as we keep our private key secure.

We also publish our public key so others can encrypt sensitive data themselves. Because we have several teams that have ownership over various pieces of sensitive information this makes managing secrets 'easy'.

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/c13c06e9-8370-4dea-8210-13774da934ae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alex Harvey]

I was thinking about a situation like this -

*) Puppet designer decides to place all credentials in a single database (encrypted Hiera).

*) developers clone the version controlled copy of it all over the place, e.g. to their laptops, that random box that everyone logs into.

*) version controlled copy then potentially sits next to copies of the keys used to decipher it.

*) some lazy developer decides not to use a passphrase in his key.

*) laptop then gets hacked, lost or stolen, etc.

Perhaps I'm being paranoid?

[jcbollinger]

On Monday, April 14, 2014 6:41:34 AM UTC-5, Alex Harvey wrote:

I was thinking about a situation like this -

*) Puppet designer decides to place all credentials in a single database (encrypted Hiera).

*) developers clone the version controlled copy of it all over the place, e.g. to their laptops, that random box that everyone logs into.

*) version controlled copy then potentially sits next to copies of the keys used to decipher it.

*) some lazy developer decides not to use a passphrase in his key.

*) laptop then gets hacked, lost or stolen, etc.

Perhaps I'm being paranoid?

Whether you are being paranoid depends on the nature of your security requirements.  Anyway, the particular scenario you raise does not present an issue localized in hiera or git, but rather an issue involving several pieces of your technology stack plus aspects of institutional and individual behavior.

The ultimate questions in security all revolve around trust: whom do you trust, about what, to what extent, and under what circumstances?  If you cannot trust developers to practice appropriate security measures -- as defined by you -- then you should not entrust them with data that need to be secured.  If your trust is limited to specific data access mechanisms or locations then those are the limits you should enforce.

Therefore, I think perhaps you are approaching the problem backward.  Instead of approaching the problem from the perspective of what might happen under various choices of infrastructure and policy, I think you should start with the security environment and policy you want, and then ask how best to get there.


John