Puppet users - Jan 2011 - Allowing puppet to drop privileges for a manifest

Greetings,

Our environment consists of about 600 Redhat Enterprise Linux 3, 4, 5,
and soon 6 servers.  We use cfengine 2 currently, but plan on
migrating to puppet.  Right now, we have our root-owned cfengine
client running every 15 minutes from cron contacting a single cfservd
server.  Additionally, our employees start their own cfengine and
puppet instances on on some servers running under their various
service accounts to manage their own software configurations (for
example, the Hadoop team does not have root access, and runs as the
''hadoop'' user with a puppet instance running as
''hadoop'').  Having
multiple configuration management daemons causes increased system load
and it generally seems wrong.

I''d like the ability to have one puppetmasterd with our normal set of
rules (after migrating from cfengine), but allow our users to add
their own manifests.  The trick is that these manifests must run as
their service account and not as root.  For example, I''d like to pull
in manifests from a hadoop/ directory, and any file edits, copies,
package installations, etc will run as the ''hadoop'' user.

I''ve been thinking about adding a custom provider, one which wraps
commands with "su -c "command" hadoop", for example, but
I''m not sure
how feasible this is.

Has anyone needed to do anything similar?  Do you have any suggests
for this new puppet user?

Thanks,

Jason

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Jan 4, 2011 10:56 AM, "Jason Parrott" <fanatic@gmail.com>
wrote:
> Our environment consists of about 600 Redhat Enterprise Linux 3, 4, 5,
> and soon 6 servers.  We use cfengine 2 currently, but plan on
> migrating to puppet.  Right now, we have our root-owned cfengine
> client running every 15 minutes from cron contacting a single cfservd
> server.  Additionally, our employees start their own cfengine and
> puppet instances on on some servers running under their various
> service accounts to manage their own software configurations (for
> example, the Hadoop team does not have root access, and runs as the
> ''hadoop'' user with a puppet instance running as
''hadoop'').  Having
> multiple configuration management daemons causes increased system load
> and it generally seems wrong.
The puppet client will happily run from cron rather than as a daemon; we
started that at a previous job in the bad old days to work around a ruby
core memory leak, but retained it because it reduced long term memory use
and so allowed us to increase VM density on our hosts.
> I''d like the ability to have one puppetmasterd with our normal set
of
> rules (after migrating from cfengine), but allow our users to add
> their own manifests.  The trick is that these manifests must run as
> their service account and not as root.  For example, I''d like to
pull
> in manifests from a hadoop/ directory, and any file edits, copies,
> package installations, etc will run as the ''hadoop'' user.
I would definitely have the hadoop people run their own puppetmaster or, at
least, provide one for them that they have control over the full manifest
set of.

(Otherwise I would have a process that you review their manifests, but
scaling that can be a challenge.)

Regards,
    Daniel

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Jan 4, 2011, at 10:42 AM, Jason Parrott wrote:
> Greetings,
> 
> Our environment consists of about 600 Redhat Enterprise Linux 3, 4, 5,
> and soon 6 servers.  We use cfengine 2 currently, but plan on
> migrating to puppet.  Right now, we have our root-owned cfengine
> client running every 15 minutes from cron contacting a single cfservd
> server.  Additionally, our employees start their own cfengine and
> puppet instances on on some servers running under their various
> service accounts to manage their own software configurations (for
> example, the Hadoop team does not have root access, and runs as the
> ''hadoop'' user with a puppet instance running as
''hadoop'').  Having
> multiple configuration management daemons causes increased system load
> and it generally seems wrong.
> 
> I''d like the ability to have one puppetmasterd with our normal set
of
> rules (after migrating from cfengine), but allow our users to add
> their own manifests.  The trick is that these manifests must run as
> their service account and not as root.  For example, I''d like to
pull
> in manifests from a hadoop/ directory, and any file edits, copies,
> package installations, etc will run as the ''hadoop'' user.
> 
> I''ve been thinking about adding a custom provider, one which wraps
> commands with "su -c "command" hadoop", for example,
but I''m not sure
> how feasible this is.
This still gives them root access.  All they need to do is use a normal
provider.

What about running both instances of puppet from cron?  That should save you the
resources.

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Jan 4, 7:13 pm, Patrick <kc7...@gmail.com>
wrote:
> On Jan 4, 2011, at 10:42 AM, Jason Parrott wrote:
>
>
>
> > Greetings,
>
> > Our environment consists of about 600 Redhat Enterprise Linux 3, 4, 5,
> > and soon 6 servers.  We use cfengine 2 currently, but plan on
> > migrating to puppet.  Right now, we have our root-owned cfengine
> > client running every 15 minutes from cron contacting a single cfservd
> > server.  Additionally, our employees start their own cfengine and
> > puppet instances on on some servers running under their various
> > service accounts to manage their own software configurations (for
> > example, the Hadoop team does not have root access, and runs as the
> > ''hadoop'' user with a puppet instance running as
''hadoop'').  Having
> > multiple configuration management daemons causes increased system load
> > and it generally seems wrong.
>
> > I''d like the ability to have one puppetmasterd with our
normal set of
> > rules (after migrating from cfengine), but allow our users to add
> > their own manifests.  The trick is that these manifests must run as
> > their service account and not as root.  For example, I''d like
to pull
> > in manifests from a hadoop/ directory, and any file edits, copies,
> > package installations, etc will run as the ''hadoop''
user.
>
> > I''ve been thinking about adding a custom provider, one which
wraps
> > commands with "su -c "command" hadoop", for
example, but I''m not sure
> > how feasible this is.
>
> This still gives them root access.  All they need to do is use a normal
provider.
>
> What about running both instances of puppet from cron?  That should save
you the resources.
Thanks for your input guys.  Although it does seem the most simple
solution would be to run separate puppet client process in cron for
each user, I''m afraid it won''t scale well long term for us.

If this catches on beyond the dozen or so users we have now, I can
imagine 1000+ service users wanting to take advantage of puppet.  At
that point, I''d be attempting to spread out the cron entries so that
they all didn''t run at the same time, but at some point my server
would be running a cron entry every few seconds, or I''d have to lower
the frequency of updates .

It seems smarter and have less overhead to let one client instance
running as root drop privileges on a per-module basis.  Has anyone
thought of, or are there any plans to extend access controls to allow
modules to be contained as a user, or perhaps even inside a chroot?
I''d really love to have one puppet client instance run and not have to
add rules to manage cron entries for every service user on a
particular system.  I could allow our employees to package and deploy
modules to our puppetmaster, and somehow guarantee that those modules
would be run in a secure way.

As a short term solution, I like the idea of running an instance of
puppet from cron per service user.  The root-owned instance would sync
the files, and the service-user-owned instances would read from their
particular subdirectory.  However, I''m still interested in a long term
solution that doesn''t involve the cron overhead across more than a
handful of users.

Thanks again,

Jason

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Wed, Jan 5, 2011 at 6:56 AM, Jason Parrott <fanatic@gmail.com> wrote:
> On Jan 4, 7:13 pm, Patrick <kc7...@gmail.com> wrote:
> > On Jan 4, 2011, at 10:42 AM, Jason Parrott wrote:
> >
> >
> >
> > > Greetings,
> >
> > > Our environment consists of about 600 Redhat Enterprise Linux 3,
4, 5,
> > > and soon 6 servers.  We use cfengine 2 currently, but plan on
> > > migrating to puppet.  Right now, we have our root-owned cfengine
> > > client running every 15 minutes from cron contacting a single
cfservd
> > > server.  Additionally, our employees start their own cfengine and
> > > puppet instances on on some servers running under their various
> > > service accounts to manage their own software configurations (for
> > > example, the Hadoop team does not have root access, and runs as
the
> > > ''hadoop'' user with a puppet instance running as
''hadoop'').  Having
> > > multiple configuration management daemons causes increased system
load
> > > and it generally seems wrong.
> >
> > > I''d like the ability to have one puppetmasterd with our
normal set of
> > > rules (after migrating from cfengine), but allow our users to add
> > > their own manifests.  The trick is that these manifests must run
as
> > > their service account and not as root.  For example, I''d
like to pull
> > > in manifests from a hadoop/ directory, and any file edits,
copies,
> > > package installations, etc will run as the
''hadoop'' user.
> >
> > > I''ve been thinking about adding a custom provider, one
which wraps
> > > commands with "su -c "command" hadoop", for
example, but I''m not sure
> > > how feasible this is.
> >
> > This still gives them root access.  All they need to do is use a
normal
> provider.
> >
> > What about running both instances of puppet from cron?  That should
save
> you the resources.
>
> Thanks for your input guys.  Although it does seem the most simple
> solution would be to run separate puppet client process in cron for
> each user, I''m afraid it won''t scale well long term for
us.
>
> If this catches on beyond the dozen or so users we have now, I can
> imagine 1000+ service users wanting to take advantage of puppet.  At
> that point, I''d be attempting to spread out the cron entries so
that
> they all didn''t run at the same time, but at some point my server
> would be running a cron entry every few seconds, or I''d have to
lower
> the frequency of updates .
>
> It seems smarter and have less overhead to let one client instance
> running as root drop privileges on a per-module basis.  Has anyone
> thought of, or are there any plans to extend access controls to allow
> modules to be contained as a user, or perhaps even inside a chroot?
> I''d really love to have one puppet client instance run and not
have to
> add rules to manage cron entries for every service user on a
> particular system.  I could allow our employees to package and deploy
> modules to our puppetmaster, and somehow guarantee that those modules
> would be run in a secure way.
>
> As a short term solution, I like the idea of running an instance of
> puppet from cron per service user.  The root-owned instance would sync
> the files, and the service-user-owned instances would read from their
> particular subdirectory.  However, I''m still interested in a long
term
> solution that doesn''t involve the cron overhead across more than a
> handful of users.
>
Can you put a feature request in for this please Jason? I can''t promise
anything, as I expect there are a fair few complicating factors that make
implementing this non-trivial, but it''s certainly worth capturing as a
feature request.

http://projects.puppetlabs.com/projects/puppet/



>
> Thanks again,
>
> Jason
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
>
puppet-users+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
>
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Jan 5, 10:59 am, Nigel Kersten <ni...@puppetlabs.com>
wrote:
> On Wed, Jan 5, 2011 at 6:56 AM, Jason Parrott <fana...@gmail.com>
wrote:
> > On Jan 4, 7:13 pm, Patrick <kc7...@gmail.com> wrote:
> > > On Jan 4, 2011, at 10:42 AM, Jason Parrott wrote:
>
> > > > Greetings,
>
> > > > Our environment consists of about 600 Redhat Enterprise
Linux 3, 4, 5,
> > > > and soon 6 servers.  We use cfengine 2 currently, but plan
on
> > > > migrating to puppet.  Right now, we have our root-owned
cfengine
> > > > client running every 15 minutes from cron contacting a
single cfservd
> > > > server.  Additionally, our employees start their own
cfengine and
> > > > puppet instances on on some servers running under their
various
> > > > service accounts to manage their own software configurations
(for
> > > > example, the Hadoop team does not have root access, and runs
as the
> > > > ''hadoop'' user with a puppet instance
running as ''hadoop'').  Having
> > > > multiple configuration management daemons causes increased
system load
> > > > and it generally seems wrong.
>
> > > > I''d like the ability to have one puppetmasterd with
our normal set of
> > > > rules (after migrating from cfengine), but allow our users
to add
> > > > their own manifests.  The trick is that these manifests must
run as
> > > > their service account and not as root.  For example,
I''d like to pull
> > > > in manifests from a hadoop/ directory, and any file edits,
copies,
> > > > package installations, etc will run as the
''hadoop'' user.
>
> > > > I''ve been thinking about adding a custom provider,
one which wraps
> > > > commands with "su -c "command" hadoop",
for example, but I''m not sure
> > > > how feasible this is.
>
> > > This still gives them root access.  All they need to do is use a
normal
> > provider.
>
> > > What about running both instances of puppet from cron?  That
should save
> > you the resources.
>
> > Thanks for your input guys.  Although it does seem the most simple
> > solution would be to run separate puppet client process in cron for
> > each user, I''m afraid it won''t scale well long term
for us.
>
> > If this catches on beyond the dozen or so users we have now, I can
> > imagine 1000+ service users wanting to take advantage of puppet.  At
> > that point, I''d be attempting to spread out the cron entries
so that
> > they all didn''t run at the same time, but at some point my
server
> > would be running a cron entry every few seconds, or I''d have
to lower
> > the frequency of updates .
>
> > It seems smarter and have less overhead to let one client instance
> > running as root drop privileges on a per-module basis.  Has anyone
> > thought of, or are there any plans to extend access controls to allow
> > modules to be contained as a user, or perhaps even inside a chroot?
> > I''d really love to have one puppet client instance run and
not have to
> > add rules to manage cron entries for every service user on a
> > particular system.  I could allow our employees to package and deploy
> > modules to our puppetmaster, and somehow guarantee that those modules
> > would be run in a secure way.
>
> > As a short term solution, I like the idea of running an instance of
> > puppet from cron per service user.  The root-owned instance would sync
> > the files, and the service-user-owned instances would read from their
> > particular subdirectory.  However, I''m still interested in a
long term
> > solution that doesn''t involve the cron overhead across more
than a
> > handful of users.
>
> Can you put a feature request in for this please Jason? I can''t
promise
> anything, as I expect there are a fair few complicating factors that make
> implementing this non-trivial, but it''s certainly worth capturing
as a
> feature request.
>
> http://projects.puppetlabs.com/projects/puppet/
>
>
>
> > Thanks again,
>
> > Jason
>
Absolutely.  Thanks Nigel.

http://projects.puppetlabs.com/issues/5779

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.