Puppet users - Apr 2013 - Allowing external users to deploy code where an existing puppet instance exists.

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.

Should I think about running a second puppet master - either under a 
different user or on a different host?

Can a puppet client talk to multiple masters?

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.

Perhaps I should be using environments for this type of setup?

Any pointers would be welcome.

Many thanks,

Richard.

-- 
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+unsubscribe@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.

Hi Richard,

I''m not certain Puppet itself will be able to fill that role properly. 
AFAIK there''s no way to limit certain manifests access to specific 
directories, or prevent others from breaking your code. Even with a bunch 
of testing, en error in some manifest could cause catalog compilation 
errors. Someone please correct me if I''m wrong.

I think you''ll need to abstract the data from the Puppet code. Perhaps,
you
can code a layer around the features your users need. Maybe a defined type 
or a provider/type that users can use, combined with a simple code-review 
tool (like Gerrit) where trusted users can review the suggested changes.

You could set up Hiera to pull data from a database or other source. Allow 
the semi-trusted users to enter that data into the database via a web-app 
or whatever. Maybe even giving them access to a directory That way you 
control the Puppet code, hence limiting what the users are allowed to 
change. They activate parts of the code by providing  data via Hiera.

Another option is to use something different altogether, though you have 
probably considered this already. We use Capistrano (actually Webistrano, a 
web frontend for it) to allow developers to deploy to production servers. 
Puppet manages the directory structure, deploy-users and permissions. 
Capistrano deploys the web application from version-control and performs 
various pre- and post-scripts such as symlinking to shared assets and 
flushing caches.

We''re starting to manage Solr cores via Capistrano as well, where we 
previously used Puppet to do that. Although it worked with Puppet, we ran 
into similar problem as you: allowing semi-trusted people to manage Solr 
cores without having them break Puppet turned out to be tricky. We use the 
basic authentication of Webistrano to control who''s allowed to do a
deploy.
Capistrano is not limited to deploying code from version-control. It''s
just
Ruby. You could write pretty much any script you want.

Maybe you could tell us a bit more about the type of actions the users need 
to be able to perform, so we''ll know what would or wouldn''t
work.

Regards, Martijn

Op maandag 8 april 2013 13:03:27 UTC+2 schreef Richard het
volgende:
>
> 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.
>
> Should I think about running a second puppet master - either under a 
> different user or on a different host?
>
> Can a puppet client talk to multiple masters?
>
> 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.
>
> Perhaps I should be using environments for this type of setup?
>
> Any pointers would be welcome.
>
> Many thanks,
>
> Richard.
>
-- 
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+unsubscribe@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.

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+unsubscribe@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.