Access to hiera repository

[Stefan Schulte]

Hello everyone,

I am currently working in a Linux team that decided to use Puppet as a
configuration management tool and we developed a couple of own modules,
use a lot from the forge and we keep hiera data in a separate git
repository (tools: r10k+controlrepo, one separate hiera repo not managed
by r10k, gitlabs server to manage all git repos)

The IT department is quite big and has different silos (e.g VMWare team,
Linux team, Backup team, Storage team, etc) but we (meaning the linux
team) want to use puppet to replace workflows that beforehand went
through different departments, e.g. to configure backup for a new
machine, the backup team had to create a node in their backup tool and
than give us the necessary input to generate the correct configuration
file on the new server.

Ideally I would like them to manage the data in hiera the same way as we
do, so they can leverage the hierarchy to define defaults on a subnet
level, host level, etc. but on the otherhand access to the single hiera
repo would allow them to basically reconfigure everything on a server
(like adding data for the sudo module to add custom sudo rules).

Even though this would be tracked through git logs, a lot of my
collegues are not comfortable with that (and might even be against
internal regulations) so I am wondering how you manage the fact when a
lot of different teams with different knowledge about puppet, yaml, and
git should contribute to hiera but should only manage stuff they care
about/are responsible for.

- Stefan

[Gerhardus Geldenhuis]

Hi Stefan,

It is a fairly common problem and until recently there has not been a very elegant solution. Have a look at http://jerakia.io/ which is a drop in replacement for Hiera. Its used in production by a Swiss bank and some other places so even though it is fairly new is more than up to the task. Jerakia offers an elegant solution to your silo problem and there is some examples and documentation on the website to get you started.

Regards

[Craig Dunn]

This also depends if your requirement is only restricting users access
to data. If thats all you need then to me this is falls more into
what tool you use to store and edit your data, rather than the one you
use to look it up, you might be able to use a hiera backend more
advanced than the simple YAML one that uses something that has the
concept of users and ACL's, maybe something like using hiera-http to
talk to CouchDB and ensure that CouchDB permissions are locked down or
one of the various database backends and store your data in something
that allows granular access.

If however you also need to change the lookup strategy, hierarchy,
data source...etc from Puppet depending on what is being configured,
then Jerakia would be a solution.

Craig

> --
> 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/1d9fb756-cdfe-468f-b0fa-4b7a90a81e2a%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.

[Christopher Wood]

(inline)

On Tue, Feb 02, 2016 at 11:38:20PM +0100, 'Stefan Schulte' via Puppet Users wrote:
> Hello everyone,
>
> I am currently working in a Linux team that decided to use Puppet as a
> configuration management tool and we developed a couple of own modules,
> use a lot from the forge and we keep hiera data in a separate git
> repository (tools: r10k+controlrepo, one separate hiera repo not managed
> by r10k, gitlabs server to manage all git repos)

Been there, but if you're managing one git repository with r10k why not manage them all?

> The IT department is quite big and has different silos (e.g VMWare team,
> Linux team, Backup team, Storage team, etc) but we (meaning the linux
> team) want to use puppet to replace workflows that beforehand went
> through different departments, e.g. to configure backup for a new
> machine, the backup team had to create a node in their backup tool and
> than give us the necessary input to generate the correct configuration
> file on the new server.
>
> Ideally I would like them to manage the data in hiera the same way as we
> do, so they can leverage the hierarchy to define defaults on a subnet
> level, host level, etc. but on the otherhand access to the single hiera
> repo would allow them to basically reconfigure everything on a server
> (like adding data for the sudo module to add custom sudo rules).

Going into creative-uses-of-hiera land, and keeping in mind that different teams can have different levels of access to individual git projects and groups, you can use the puppet environment (or another variable) to differentiate hiera levels. The git repos can be kept up to date with r10k. The individual teams don't need access to the puppetmasters, you can use an mcollective plugin or git commit hooks or some related solution to keep r10k going.

:hierarchy:
- 'r10k/%{environment}/hieradata/datacenters/%{datacenter}
- 'r10k/%{environment}/hieradata/clusters/%{cluster}

I assume in this scenario your environments would be "backup", "storage", and so on. Something broadly similar is working well enough for us, but to be perfectly frank, getting your organization on the same page is going to be the harder part of the task.

> Even though this would be tracked through git logs, a lot of my
> collegues are not comfortable with that (and might even be against
> internal regulations) so I am wondering how you manage the fact when a
> lot of different teams with different knowledge about puppet, yaml, and
> git should contribute to hiera but should only manage stuff they care
> about/are responsible for.

You should re-read those internal regulations before you attempt to change your puppetmaster internals.

> - Stefan
>
> --
> 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/56B12FDC.8090801%40taunusstein.net.