voxpupuli / hiera-eyaml

A backend for Hiera that provides per-value asymmetric encryption of sensitive data
MIT License
527 stars 130 forks source link

Is there or will there be support for multiple encryption keys #159

Closed Tokynet closed 9 years ago

Tokynet commented 9 years ago

I would like to have the ability to use different encryption keys so I may encrypt different application's data with unique Keys. My main concern is if we start signing everything with same key and that key gets compromised it will be an ugly fire-drill to clean up.

One way I think this can be accomplished is by adding named/numbered datadir fields like this:

:eyaml: :datadir_1: '/etc/puppet/hieradata/app1' :datadir_2: '/etc/puppet/hieradata/app2'

# If using the pkcs7 encryptor (default)
:pkcs7_private_key_1: /path/to/private_key.pkcs7.pem
:pkcs7_public_key_1:  /path/to/public_key.pkcs7.pem
:pkcs7_private_key_2: /path/to/private_key.pkcs7.pem
:pkcs7_public_key_2:  /path/to/public_key.pkcs7.pem

Thanks

soumentrivedi commented 9 years ago

[TESTED] you might want to look into https://gist.github.com/soumentrivedi/24bb3fb135085d004c1d , this is how we use separate encryption keys for different directory based environments in puppet.

[NOT TESTED, In Theory] If you want to use multiple keys for different application within a single puppet environment, I believe you can chain multiple pem into a single pem, use the relevant public key pem to encrypt and use the single private pem file to decrypt.

sihil commented 9 years ago

If you want better key management then I'd suggest a leap to hiera_eyaml_gpg. Along with the recipient files, this is a good way of using multiple keys and making key rotation easier to manage.

soumentrivedi commented 9 years ago

@sihil thanks for sharing details on this. I will give this a go :)

neoice commented 9 years ago

this is relevant to my interests. my $work is using hiera-eyaml with git+Puppet. my boss is interested in using hiera-eyaml to replace KeePass. to me, the ability to selectively grant access based on job role would be amazing (ex: have keys systems.pem, databases.pem, external.pem, etc. give DBAs only databases.pem)

I'm not sure if it's technically feasible or if it's even a good idea... but it might be an interesting problem to solve!

Tokynet commented 9 years ago

Thanks for the comments, i will look into hiera_eyaml_gpg.

Just to leave more information, we are about to look at a tool ($) called conjur which does secret management and provides a nice cli and API.

neoice commented 9 years ago

@Tokynet conjur looks very similar to vault: https://www.vaultproject.io/

the main problem I saw with vault was there's not a good way to list/browse the secrets. here's an issue open about it.

Tokynet commented 9 years ago

@neoice I will look into vaultproject. I do not see the need to browse secrets, I refer/call them explicitly on my manifests. If you mean a way to just see them all but not actually use them, i believe the conjur web-interface would allow you to do it.

TomPoulton commented 9 years ago

If you want a separate set of keys per environment I would definitely go down @soumentrivedi's route as it follows the already established %{::environment} pattern!

If you're looking for more role/individual based keys then definitely check out @sihil's hiera-eyaml-gpg backend to get all the benefits of gpg keychains

I'm going to close this issue, but if anyone has a use-case that isn't addressed by either of these methods, feel free to re-open

h-svab commented 9 years ago

I've implemented a backend for multiple pkcs7 keys: hiera-eyaml-p7b. Unfortunatly it needs a patched version of eyaml:

---
encrypt_method: 'p7b'
p7b_private_key: '/home/user/.eyaml/ssl/user_private_key.pem'
p7b_public_key:  '/home/user/.eyaml/ssl/user_public_key.pem'
p7b_public_keys: '/home/user/.eyaml/ssl/user_public_key.pem,/home/user/.eyaml/ssl/server_public_key.pem'