On Monday, April 8, 2013 6:03:27 AM UTC-5, Richard wrote:
Hi All,
I'm currently using puppet to deploy our O/S configuration to servers.
I've got a requirement to allow a semi-trusted set of external users to
deploy application configuration onto these same hosts. For example,
they'd be allowed to configure anything under a /apps directory.
What would be the best way to achieve this? Ideally, I don't think I want
to give them access to our puppet master, although if we really had to we
could, and restrict them to a set of directories on the master using
appropriate permissions.
Doing as you describe would not affect what parts of target nodes the
external users could configure.
Should I think about running a second puppet master - either under a
different user or on a different host?
Probably not.
Can a puppet client talk to multiple masters?
Each agent must be paired with one master. It is possible to configure
multiple agents on the same node, talking to different masters, but I don't
recommend it.
If you were to do it anyway, however, then you would want to make sure that
the external users' agent only had access to those parts of target nodes
that it was supposed to be able to change. That would certainly mean not
running it as root, which in turn implies that it could not manage anything
that requires root access. In the end, that probably means it could manage
only the contents of certain directories, and when you reduce it to that
level there are better options (such as a scheduled sync of the target
directories with a source-control repository).
Is there any way to restrict them so they can only write modules that
update files under the /apps filesystem? For example, if I'm populating
/etc/hosts via an existing class, I don't want them to be able to write
something that conflicts with this.
Puppet does not have a mechanism for restricting which target resources a
given module may manage.
If you are looking only to protect against accidental conflicts, then
Puppet provides limited protection automatically by failing catalog
compilation when it sees multiple declarations of the same resource. You
could set up monitoring to detect that. Indeed, your own team could cause
the same kind of problem, so it's worth watching out for it in any case.
That does absolutely nothing to protect against malicious interference with
your systems' configurations, however. Modules installed in your
puppetmaster can cause agents to do literally anything that target nodes'
security framework allows them to do, so anyone who can modify any modules
without oversight and code review is *de facto* trusted.
Perhaps I should be using environments for this type of setup?
Environments would help you only if there were some systems on which your
external users could be fully trusted, but others on which they were not.
That could play a part in a review process for module updates, or it might
naturally fit with what you're trying to do, but it doesn't achieve what
you started out asking about.
Any pointers would be welcome.
Puppet is very powerful, but with great power comes great responsibility.
People to whom you are unwilling to grant such responsibility must not be
given access to your master. That extends even to ERB templates, for Ruby
code running in such a template can accidentally or maliciously muck with
Puppet internals (though doing so accidentally is unlikely).
You can allow your external users to upload flat application configuration
files or flat file fragments to a source-control system from which the
master will periodically pull. That limits your exposure to only the
application(s) being configured. The module that actually manages the
target files based on these sources should be reviewed and approved by your
team. You can also allow users to manage ERB templates if you trust them
to be competent and benign. You probably should set up permissions so that
the puppetmaster process has read-only access to its manifests and other
data (which is good on general principles).
John
--
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+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
