Add custom hiera backend for trocla

[michaelweiser]

I wrote a custom hiera backend for trocla. Would you be interested in it?

I made some design decisions open for discussion:

• To get additional parameters for the trocla function on a per-password basis, the lookup function of the custom backend does itself do hiera lookups.
• To prevent loops, the backend only reacts to namespace trocla::password:: and does all additional lookups into trocla::options::

This means that password creation has to be triggered via explicit hiera function interpolation lookups such as:

kerberos::kdc_database_password: "%{hiera('trocla::password::kdc_database_password')}"

I looked into just adding a "%{trocla('<key>')}" function but there's no API for that and the existing functions hiera and scope are pretty hard-coded in the hiera source. Getting trocla-support in there without adding a whole extension function API is unlikely.

• It implements the actual hiera hierarchy by pre-pending the hiera path to the trocla key as hiera/<source>/<trocla_key>. This way, the same trocla key could yield different passwords for different groups of machines. I'm not sure, how much use this would actually be in practice. Also, that key would need to be initialised externally, e.g by calling trocla('hiera/osfamily/Debian/jessie/root' in site.pp. Alternatively we could use hiera's concept of datafiles to look into different trocla password stores. But this would need somehow providing different troclarcs as well.

Only reacts to key namespace trocla::password::<trocla_key>. Looks up
additional parameters via hiera itself as
trocla::options::<trocla_key>::format (string) and
trocla::options::<trocla_key>::options (hash). Looks for <trocla_key> in
trocla as hiera/<source>/<trocla> with <source> iterating over the
configured hiera hierarchy. If not found, creates and returns a new
password with trocla key <trocla_key>.

example entry in hiera.yaml:

backends:
  - ...
  - trocla
trocla:
  - configfile: /etc/puppet/troclarc.yaml
  - format: plain
  - options:
    length: 16

example usage in hiera yaml file:

kerberos::kdc_database_password: "%{hiera('trocla::password::kdc_database_password')}"
trocla::options::kdc_database_password::format: 'plain'
trocla::options::kdc_database_password::options:
  length: '71'

[duritong]

Hi

in general I like your Idea, although I haven't yet looked into it in detail.
But I was already thinking a couple of times how this could be achieved and I like your idea, but I'd like to reflect a bit more on it.

Nevertheless, I really appreciate this PR! Thanks a lot!

[duritong]

I like it, I guess I will do a few optimizations, but in general I'm fine. Thanks a lot!

[duritong]

Could you have a look at cbd411b and tell me whether it still works and what you think off.

The only thing left is whether we should hash-merge the options on the trocla.password(), as this might not be expected and I'm not sure if we actually need that and hence should just stick with the normal hiera lookup behavior.

[michaelweiser]

Well, it certainly looks a lot more elegant now and seems to work just fine after applying #16.

As for hash merge vs. priority first lookups: I'm a total sucker for hash merges because I like the flexibity and conciseness (non-redundancy) in spite of the potential for occasional confusion due to unexpected interactions or precedence. An adminttedly constructed but IMO quite conceivable real world example: I need a password with length 16 chars on standard systems (so I have a slight chance of remembering them) but 32 chars for those in the DMZ (because some policy says so). I also need it to be shellsafe on Debian boxes because their funky default of /bin/sh being dash instead of bash lets all hell break loose otherwise:
hiera.yaml:

:hierarchy:
  - "osfamily/%{::osfamily}"
  - dmz
  - common

common.yaml:

service_pwd: "%{hiera('trocla::password::service_pwd')}"
trocla::options::service_pwd::format: 'plain'
trocla::options::service_pwd::options:
  length: '16'

dmz.yaml:

trocla::options::service_pwd::options:
  length: '32'

osfamily/Debian.yaml:

trocla::options::service_pwd::options:
  charset: 'shellsafe'

[duritong]

I'm also fine with the hash_merge behavior and use it a lot. Experience just tell me, that a lot of people struggle with grasping the concept behind it. let's leave it like that for now.