Doesnt work for long values about hiera-eyaml HOT 7 CLOSED

I've also come across this issue when trying to encrypt a SSL private key. I like the per value idea, but this doesn't quite work for me yet.

I wonder if we can make this work with GPG as well or instead (this works well for my team where we encrypt to the public keys of everyone in the team).

I know this probably isn't the place for this discussion, but would it make more sense to have a different format for identifying encrypted blocks in eyaml files (see below)? scheme could have a sensible default, defined in the hiera.yaml; any keys that do not have a sub key encrypted: true would be interpreted as normal values.

key_name_to_encrypt:
  encrypted: true
  scheme: gpg
  data: >
    -----BEGIN PGP MESSAGE-----
    Version: GnuPG v1.4.11 (GNU/Linux)

    hQEOA1ZErG3LwrExEAP/R4564VgtM/9rC7zrAfqLfRkgoGplnsc+Hhn47na0xdLo
    7GgWBoV89AcL/Z03bnI0Nc1PQ/erf3avo3XP5JO6f4qXL13GlLn5eUjYg4R1WNNg
    var9CWvCZsKZ2Zf2Kdi7vyg1NAxglmtJAqEaJTubR+ORwFTWI4uIsG5+gYxsUjAE
    ...
    -----END PGP MESSAGE-----

Feel free to shoot me down.

Another option might be using GPG[] etc etc. but having a place for more data would allow an easier way of editing files... you might have a tool, say vim-eyaml, that would decrypt the file, let you edit the contents and the re-encrypt afterwards. It would need some markup to determine which keys should be encrypted, using what form of encryption and which should remain as plain text. Further metadata might be used (in the GPG world at least) to specify which users a particular key should be encrypted for.

I probably have some time to work on this in the background, although my Ruby skills are poor I'm afraid.

from hiera-eyaml.

Hi,

The reason I chose hiera-eyaml rather than hiera-gpg was because of its ultimate simplicity and readability -

i .e. having:

some_key: some_value
another_key: ENC[af90sug09sdg] # encrypted value

is a big plus for me - it makes my yaml files really readable, and I dont have the side-effects of hiera-gpg (the keys are encrypted too, so I dont even know what they're called.)

In addition, having a simple public_key and private_key I find a lot simpler than the hiera-gpg setup where I need a .gnupg database directory somewhere as well.

I think it would be a shame to lose the simplicity - I thought hiera-eyaml was really elegant, and think if we can fix the issue whilst keeping the same elegant mechanism, it would be a real winner. Having said that I can apprecitate you wanting to have different forms of encryption as alternatives to the user.

In that case I would suggest something like:

some_rsa_encrypted_property: ENC[RSA,abs0d0s9dfsdg….]
some_gpg_encrypted_property: ENC[GPG,afsd8232335]

with the default mechanism being RSA if an encoding isnt specified

some_encrypted_property: ENC[abc89389d….]

I will spend some time today working on a solution for the issue for the RSA keys as I've read that it should be simple with a couple of minor tweaks, and no change to the yaml you're currently using. Will let you know how I get on..

from hiera-eyaml.

I have created a pull request to fix everything. See what you think

from hiera-eyaml.

I wrote hiera-eyaml because me and GPG weren't getting along and it seemed too sensitive and "cryptic", I know that's a stupid thing to say as that's kind of the idea when it comes to encryption, but I wanted the system to be easily understood by anyone who had to maintain it.

I do appreciate the need for flexibility though and whilst hiera-eyaml might be suited to MY needs, it might not be suitable for everyone in it's current state so thanks for your thoughts. I think we're all thinking along the same lines so if we could implement a stable GPG solution (or another encryption method) then we could do something like the following:

some_rsa_encrypted_property: RSA[abs0d0s9dfsdg]
some_gpg_encrypted_property: GPG[afsd8232335]

That way we can keep configuration in the hiera.eyaml file for the backend and limit the amount of meta-data we include alongside the encrypted values.

Geoff has implemented some changes (mentioned above) that look really helpful and solves the problem of storing long strings. Simon If we could store long strings would that meet all your requirements or are there other things about GPG that you like? I know that GPG can handle multiple keys in its keychain, is that what you were referring to when you mentioned your team's keys?

Thanks your for comments, keep them coming!

from hiera-eyaml.

Thanks for the reply @TomPoulton - it's looking very promising, especially with the polish that @gtmtech has been adding over the last couple of days.

The benefits of hiera-eyaml for me is primarily around the transparency of the keynames and being able to easily understand what keys in a particular file changed using git diff etc. The opaque nature of hiera-gpg makes this very hard. To some extent I believe that the benefit of this is strong enough that I don't mind so much about the particular encryption approach that is used.

However you are spot on when you talk about multiple keys in the keychain. Using GPG you can encrypt a document specifying multiple public keys. As a result it is possible for any of the corresponding private keys to decrypt the content.

This is useful in at least two scenarios. The first I mentioned before - that I can encrypt a value using the public keys of everyone in my operations team (as well as the public key corresponding to the puppet master running the hiera backend). Any of my team mates can then decrypt the value themselves. The second is that it makes life a whole lot easier if you need to rotate your keys as re-encrypting the files does not have to be done in lockstep with replacing the keys on the puppet masters. The files can be re-encrypted, adding the new public key - then the puppet masters can be updated and finally the old key can be removed by re-encrypting the eyaml files again. Oh and the third reason is allowing different puppet masters to use different private keys (you could have a PROD and DEV keypair for example - and encrypt different values using different keys). The third reason isn't a concern for me at the moment, just another example of the flexibility.

It might be possible to encrypt to multiple keys using the PKCS#7 scheme that Geoff has used. But I work in a team where we already have GPG keys, so that is the most obvious choice :)

Have a great weekend!

from hiera-eyaml.

Hi all,

I love the suggestion of having PKCS7 and GPG as different encryption methods available, and can clearly see some advantages with the GPG mode as Simon says above.

One thing I will say though, another annoyance for me with hiera-gpg is that it depends on the gpgme gem which is not a pure ruby gem. I.e. it requires native compilation. In our production systems this means I have to make my own rpm/deb of it in order to install it, as we dont allow gcc on our production systems, which is a bit of a headache that I dont have with hiera-eyaml and openssl because its part of ruby core.

If you make hiera-eyaml depend on gpgme to get the same functionality it'll have the same disadavantage.. what I suggest is you allow different encryption methods as "plugins" for hiera-eyaml, maintained in separate projects/gems. For example I can see hiera-eyaml-gpg which has a gem dependency on hiera-eyaml. This would solve both situations.

What do you think? If you agree I'd be happy to do some work to turn the existing PKCS7 into a plugin for eyaml (whilst keeping it part of the overall hiera-eyaml project) so installing hiera-eyaml and hiera-eyaml-gpg gems will get you both encryption methods.

But I'll wait for a bit, as there are lots of pull requests going on now :-) Happy days!

from hiera-eyaml.

I've opened a new issue for this as the original issue of encoding long values has now been fixed by pull request #4.

from hiera-eyaml.