duritong / puppet-trocla

puppet integration for trocla
11 stars 18 forks source link

Add custom hiera backend for trocla #15

Closed michaelweiser closed 8 years ago

michaelweiser commented 8 years ago

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

I made some design decisions open for discussion:

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.

Only reacts to key namespace trocla::password::. 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 commented 8 years ago

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 commented 8 years ago

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

duritong commented 8 years ago

Could you have a look at cbd411b919cf7e75966ad13ffc5e654b51c8d207 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 commented 8 years ago

Well, it certainly looks a lot more elegant now and seems to work just fine after applying https://github.com/duritong/puppet-trocla/pull/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 commented 8 years ago

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.