Puppet users - Sep 2012 - multiple puppet masters on multiple subnets

Hi all,

I am interested to hear from anyone who might have deployed Puppet in a
large organisation with a lot of subnets firewalled off from each other.

I am considering to have, if possible, a ''master'' Puppet
Master controlling
''client'' Puppet Masters that live on the firewalled subnets. 
I would like
to allow the client Puppet Masters communicate with the master Puppet
Master only for the purpose of obtaining their manifests for the local
subnet.  The Master Puppet Master in turn would talk to a single git/code
server.  Then of course all the Puppet clients on each subnet would only
know about the local Puppet Masters.

Has anyone done this before or have any advice on whether or not this is a
good idea?

Best wishes,
Alex Harvey

-- 
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.

Hi,

without describing your threat analysis, there is little we can suggest. 
Depending on its contents, it might be enough to leverage(sic!) the 
existing ACL controls, confining each agent to certname specific 
locations or you''d have to have completely separate masters to avoid a 
central exploitation.

Best Regards, David

On 26.09.2012 10:14, Alex Harvey wrote:
> Hi all,
>
> I am interested to hear from anyone who might have deployed Puppet in a
> large organisation with a lot of subnets firewalled off from each other.
>
> I am considering to have, if possible, a ''master'' Puppet
Master
> controlling ''client'' Puppet Masters that live on the
firewalled
> subnets.  I would like to allow the client Puppet Masters communicate
> with the master Puppet Master only for the purpose of obtaining their
> manifests for the local subnet.  The Master Puppet Master in turn would
> talk to a single git/code server.  Then of course all the Puppet clients
> on each subnet would only know about the local Puppet Masters.
>
> Has anyone done this before or have any advice on whether or not this is
> a good idea?
>
> Best wishes,
> Alex Harvey
>
> --
> 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.
-- 
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 26 September 2012 09:14, Alex Harvey <alexharv074@gmail.com> wrote:
> Hi all,
>
> I am interested to hear from anyone who might have deployed Puppet in a
> large organisation with a lot of subnets firewalled off from each other.
>
> I am considering to have, if possible, a ''master'' Puppet
Master
> controlling ''client'' Puppet Masters that live on the
firewalled subnets.  I
> would like to allow the client Puppet Masters communicate with the master
> Puppet Master only for the purpose of obtaining their manifests for the
> local subnet.  The Master Puppet Master in turn would talk to a single
> git/code server.  Then of course all the Puppet clients on each subnet
> would only know about the local Puppet Masters.
>
> Has anyone done this before or have any advice on whether or not this is a
> good idea?
>
> Best wishes,
> Alex Harvey


I guess there is no reason why you can''t use puppet to manage slave
puppet
masters, but I think you may be adding more to your plate. Why is it a bad
idea for all your nodes to talk to one Puppet master?

-- 
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.

Hi Alex,

I attempted to set this up a while ago but never got to finish my module.
I still have it somewhere and I will likely need to finish it soon as
I need to do a similar setup soon for a PCI setup.

Another option would be to put all your puppet code into a git repo
and setup each master to pull from a central repo over ssh.
That _Should_ be secure enough.

I am also curious why you need this sort of setup.
Is it for PCI compliance or something similar?

Pete.

On 26 September 2012 18:14, Alex Harvey <alexharv074@gmail.com>
wrote:
> Hi all,
>
> I am interested to hear from anyone who might have deployed Puppet in a
> large organisation with a lot of subnets firewalled off from each other.
>
> I am considering to have, if possible, a ''master'' Puppet
Master controlling
> ''client'' Puppet Masters that live on the firewalled
subnets.  I would like
> to allow the client Puppet Masters communicate with the master Puppet
Master
> only for the purpose of obtaining their manifests for the local subnet. 
The
> Master Puppet Master in turn would talk to a single git/code server.  Then
> of course all the Puppet clients on each subnet would only know about the
> local Puppet Masters.
>
> Has anyone done this before or have any advice on whether or not this is a
> good idea?
>
> Best wishes,
> Alex Harvey
>
> --
> 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.
-- 
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 Thursday, September 27, 2012 9:13:32 AM UTC+10, Pete
wrote:
>
> Another option would be to put all your puppet code into a git repo 
> and setup each master to pull from a central repo over ssh. 
> That _Should_ be secure enough. 
>
> I am also curious why you need this sort of setup. 
> Is it for PCI compliance or something similar? 
>
Yeah, that''s my plan B.

As I mentioned I am working in a large organisation and the security people 
have a lot of power.  A Puppet Master can in principle do a lot of damage 
because you are effectively "root everywhere at once".  So
it''s simply
unlikely that our security people are going to let a single Puppet Master 
be in control of all these subnets, and the point where it is going to get 
rejected is if I ask for every host on subnet A to be allowed to talk to 
the Puppet Master that lives on subnet Z.  Whether this is a good or bad 
security policy could be debated but it''s not up to me.

An alternative is to have a central repo server as suggested here.  I could 
have independent Puppet Masters on all the subnets and that would probably 
satisfy the security requirement.  The trouble is I would then lose the 
ability to have a global view of everything.  Thus, if I wanted, say, a 
report of all hosts I manage with a special configuration of some service, 
I''ll have to log into all the Puppet Masters individually to get this 
information - or write a script to somehow extract it from the git repo.  
So I will have lost one of the key benefits of Puppet.

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/huzW1IAfegEJ.
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 27.09.2012 09:24, Alex Harvey wrote:
>
>
> On Thursday, September 27, 2012 9:13:32 AM UTC+10, Pete wrote:
>
>     Another option would be to put all your puppet code into a git repo
>     and setup each master to pull from a central repo over ssh.
>     That _Should_ be secure enough.
>
>     I am also curious why you need this sort of setup.
>     Is it for PCI compliance or something similar?
>
>
> Yeah, that''s my plan B.
>
> As I mentioned I am working in a large organisation and the security
> people have a lot of power.  A Puppet Master can in principle do a lot
> of damage because you are effectively "root everywhere at once". 
So
> it''s simply unlikely that our security people are going to let a
single
> Puppet Master be in control of all these subnets, and the point where it
> is going to get rejected is if I ask for every host on subnet A to be
> allowed to talk to the Puppet Master that lives on subnet Z.  Whether
> this is a good or bad security policy could be debated but it''s
not up
> to me.
>
> An alternative is to have a central repo server as suggested here.  I
> could have independent Puppet Masters on all the subnets and that would
> probably satisfy the security requirement.  The trouble is I would then
> lose the ability to have a global view of everything.  Thus, if I
> wanted, say, a report of all hosts I manage with a special configuration
> of some service, I''ll have to log into all the Puppet Masters
> individually to get this information - or write a script to somehow
> extract it from the git repo.  So I will have lost one of the key
> benefits of Puppet.
Thanks for clarifying the situation. In this case, emphasizing the 
separation of configuration and reporting seems to be necessary.

On the part of the configuration, you''ll have a "hole"
regardless of
whether you connect to a central master or you clone from a central 
repository. In the latter case you could add a verification step on 
signed git tags, but that still is only as secure as you private key. 
Paranoia can make you do strange things.

On the part of the reporting, you can post the reports from each 
puppetmaster to a central dashboard/puppetdb instance and have that 
write-only. That again can be made arbitrarily separated by writing out 
the reports on the master into a file and sneaker-netting that over to 
the reporting server.



Best Regards, David

-- 
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 27 September 2012 17:24, Alex Harvey <alexharv074@gmail.com>
wrote:
>
>
> On Thursday, September 27, 2012 9:13:32 AM UTC+10, Pete wrote:
>>
>> Another option would be to put all your puppet code into a git repo
>> and setup each master to pull from a central repo over ssh.
>> That _Should_ be secure enough.
>>
>> I am also curious why you need this sort of setup.
>> Is it for PCI compliance or something similar?
>
>
> Yeah, that''s my plan B.
>
> As I mentioned I am working in a large organisation and the security people
> have a lot of power.  A Puppet Master can in principle do a lot of damage
> because you are effectively "root everywhere at once".  So
it''s simply
> unlikely that our security people are going to let a single Puppet Master
be
> in control of all these subnets, and the point where it is going to get
> rejected is if I ask for every host on subnet A to be allowed to talk to
the
> Puppet Master that lives on subnet Z.  Whether this is a good or bad
> security policy could be debated but it''s not up to me.
Yeah I can understand that. I guess being the only guy in the shop
means I get to approve all the security as well.
You could involve the security people in the approval process and
change management process for your modules.
Keeping them involved is the best way. That way they also have input
into the process and point out anything that doesn''t fit within the
security policies for your organisation.

I am actually using puppet to apply the security policies so that may
be something you could consider (yeah I intent to publish my modules
when I am happy with them)
> An alternative is to have a central repo server as suggested here.  I could
> have independent Puppet Masters on all the subnets and that would probably
> satisfy the security requirement.  The trouble is I would then lose the
> ability to have a global view of everything.  Thus, if I wanted, say, a
> report of all hosts I manage with a special configuration of some service,
> I''ll have to log into all the Puppet Masters individually to get
this
> information - or write a script to somehow extract it from the git repo. 
So
> I will have lost one of the key benefits of Puppet.
You could setup puppet to manage the git repo for your modules and manifests :)
You could use tags to version the modules and include that as part of
the change management process.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/puppet-users/-/huzW1IAfegEJ.
>
> 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.
-- 
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.

Thanks guys, I really appreciate the responses here.  

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/xGWoov-8j58J.
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.