I was coming in here to say the same thing John said. Your sudoers
definition is going to be a combination of code (include sudo; sudo::conf
{'whatever':}) and data (the sudo::conf attributes). That data can be
embedded in your code, or come from a hiera/lookup backend. Both of those
should be in some form of revision control with proper review policies and
permissions. This ensures that only the correct people can submit/merge
changes, and that all merged code is reviewed before it makes it to
production.I recommend Gary's blog post http://garylarizza.com/blog/2015/11/16/workflows-evolved-even-besterer-practices/ starting with the section "Just put it in the control repo" (lots of other good articles on the site as well). It describes some of the workflow impacts of a consolidated repo, and how that might be a positive or negative toward control of your data. As I read the recommendations, there are certainly valid reasons to keep some things out of the control repo, but only if you explicitly need to. It's up to you to determine if you need to, or if your code review and gating processes are sufficient. Rob Nelson rnels...@gmail.com On Thu, May 19, 2016 at 9:06 AM, jcbollinger <john.bollin...@stjude.org> wrote: > > > On Wednesday, May 18, 2016 at 7:05:48 PM UTC-5, Alex Scoble wrote: >> >> Hi all, >> >> We're currently on PE 3.8.4. >> >> We need to be able to manage sudoers permissions with Puppet, but control >> things so sudoers permissions can only be granted within a specific module. >> >> So permissions could be included via 'include foo::bar' from anywhere, >> but the actual sudoers permissions used by the include could only be set >> within the specific module that has access tightly controlled. >> >> The goal is to prevent someone from injecting a new sudoers rule in to a >> module/manifest outside of our control. >> > > > I don't think there is any reliable way to do what you ask from within > Puppet. You may be able to achieve it by completely protecting the sudo > configuration from Puppet via mandatory access controls (SELinux) or a > similar mechanism, but then Puppet cannot manage it at all. Perhaps that's > ok, but it seems rather pointless: if you do not trust your own manifests, > then you are in a world of hurt. > > There are innumerable things that an assailant wanting to breach your > security could do with the ability to influence nodes' catalogs, and > closing down just a single avenue -- if that were even possible -- misses > the forest for the trees. Anyone who can inject a single File or Exec > resource into a node's catalog can very likely take control of that node if > they so desire. Therefore, I recommend procedural safeguards: control > access to all your manifests, perform code reviews for all changes, etc.. > > > 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 view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-users/f6dbf98e-03d8-40f2-92a1-a1807ffc2441%40googlegroups.com > <https://groups.google.com/d/msgid/puppet-users/f6dbf98e-03d8-40f2-92a1-a1807ffc2441%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAC76iT_rXohGO9aFGeT7HGVeyS1cquW%2Bg4K6b99rnUT6Gddjmg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
