encrypting hiera data?

[dkoleary]

Hey;

I've come to the point where I need to encrypt a password in hiera data.  After trying (and failing) the recipe in the puppet cookbook, I hit the google searches and very quickly came across hiera eyaml.  

So, short question: is hiera.eyaml the generally accepted method of encrypting data for use in modules?

Just trying to avoid going down the wrong path again...

Thanks

Doug O'Leary

[Christopher Wood]

Puppet at least plugs it in their blog.

https://puppet.com/blog/encrypt-your-data-using-hiera-eyaml

We've had lots of good uses for it in production.

> --
> 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 [1]puppet-users...@googlegroups.com.
> To view this discussion on the web visit
> [2]https://groups.google.com/d/msgid/puppet-users/82dd1d76-e583-48ed-b0f0-d77f792e6029%40googlegroups.com.
> For more options, visit [3]https://groups.google.com/d/optout.
>
> References
>
> Visible links
> 1. mailto:puppet-users...@googlegroups.com
> 2. https://groups.google.com/d/msgid/puppet-users/82dd1d76-e583-48ed-b0f0-d77f792e6029%40googlegroups.com?utm_medium=email&utm_source=footer
> 3. https://groups.google.com/d/optout

[Jeffrey Miller]

It's one way to go. Another way is to use GPG encryption using https://github.com/StackExchange/blackbox . All depends the requirements at your site.

-Jeffrey

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/20160708134609.GA28943%40iniquitous.heresiarch.ca.

For more options, visit https://groups.google.com/d/optout.

[dkoleary]

Thanks.  I'll take a look.  I appreciate the response.

>    1. mailto:puppet-users+unsub...@googlegroups.com

[Andrew Grimberg]

Hiera eyaml works very well, particularly if paired with the GPG backend
as you don't have to share a PKCS private key among all the entities
that need to decrypt data.

It's also really useful to use the GPG backend as this allows you to
segment who can, and cannot decrypt certain data, allowing you to share
your hiera tree across teams and use a single puppet role / profile
design where just the data is environment specific.

-Andy-

[Andreas Zuber]

Hi

While eyaml is great for storing existing passwords or certificates in your hieradata, there are usually also password no one actually has to know (db passwords, etc.).

To automate this we use trocla ( https://github.com/duritong/trocla ) and it's hiera backend ( https://github.com/ZeroPointEnergy/hiera-backend-trocla ) to automatically generate this passwords on the puppetmaster when they are needed.

--
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/82dd1d76-e583-48ed-b0f0-d77f792e6029%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Simon Hönscheid]

Hi Doug,

hiera-eyaml or trocla (random generation and storage backend(use mysql)) are your friends. If you just want to encrypt hiera data try hiera-eyaml.
I prefer the gpg backend.

Kind Regards

Simon

Am 08.07.16 um 15:29 schrieb dkoleary:

[Zee Alexander]

<opinion>

 
I'll just add...yes hiera-eyaml is the generally accepted "puppet community" way of encrypting data in hiera. BUT, puppet in general is not ideal for secret storage at this time. E.g. the benefit of hiera eyaml is that people can contribute encrypted values via the public key, to a git repo, without having the private key to decrypt. It doesn't offer you any particularly special security on the puppet master, since by definition the master is going to have a copy of the private key so that it can decrypt data, and it's going to be plaintext in the catalog regardless (which ends up cached on the agent node...)

Not to mention storing credentials in YAML is inherently a duplication of that information (vs whatever spreadsheet/lastpass/1pass type thing you use), and if you do enough of it, things are going to get out of sync between hiera and reality no matter how hard you try.

Ideally you'd use some sort of API-based credential storage so that nodes can retrieve their credentials ad-hoc.

Hashicorp Vault is one example: https://www.vaultproject.io/

Conveniently, there's a hiera backend for it: https://github.com/jsok/hiera-vault

Ideally there'd be some sort of node-side retrieval so that the credentials don't end up in the catalog, but that's an exercise left to the reader.

</opinion>

[Massimiliano Adamo]

Zee, 

<opinion>

There is no need to read the password from the catalog, since the password for your DB is stored on some XML, in the application server. 

The point is that in the real world most developers don't have access to production servers and they only need to access the code in the versioning (puppet, hiera and so on). 

Only few devops/administrators have access to puppet server and production servers. 

hiera-vault is nice, but it's convoluted and might be overkilled for the easy task of encrypting few keys. 

You might not need any API and any cumbersome that Hashicorp often has in his head. You just need to encrypt some stuff on your hiera, in a way that you can share the code with everyone, without revealing all the secrets. 

Vault might offer other features that I am not aware, but you really need to know these features and understand if you're really gonna use them 

Massimiliano