Curse GW Bush and his ''Axis of Evil'' - my google searches are contaminated with hits to Korea, and other such fun... Does anyone have any experiences with puppet in the DMZ they can share? At my puppet master training (Hi Hunter), it was mentioned some people compile their catalogs inside, then ship them out to servers in the DMZ to be applied. I understand that fine, but we use facts quite a bit to get state information, so the traditional part of the client server/model where facts are shipped back from the client to the puppet server is missing. How do people get around the "common" rule that DMZ servers should not initiate network connections back to the internal network? Should we have a puppet server in the DMZ? Thanks John -- 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 Feb 10, 2011, at 10:25 PM, John Warburton wrote:> Curse GW Bush and his ''Axis of Evil'' - my google searches are contaminated with hits to Korea, and other such fun... > > Does anyone have any experiences with puppet in the DMZ they can share? > > At my puppet master training (Hi Hunter), it was mentioned some people compile their catalogs inside, then ship them out to servers in the DMZ to be applied. > > I understand that fine, but we use facts quite a bit to get state information, so the traditional part of the client server/model where facts are shipped back from the client to the puppet server is missing. > > How do people get around the "common" rule that DMZ servers should not initiate network connections back to the internal network? Should we have a puppet server in the DMZ?Just in case you didn''t think of these already: If you do ship out catalogs manually, you can''t use the "puppet:///modules/module..." style file serving. Everything done with "content" should still work. Next keep in mind that for "Package" to work, you need to be able to see the package repository. -- 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 Thu, Feb 10, 2011 at 22:25, John Warburton <jwarburton@gmail.com> wrote:> Does anyone have any experiences with puppet in the DMZ they can share?We looked at how to integrate puppet into a network that needed medical-in-confidence certification back in Australia, which is probably about the same level of security control that most business DMZ deployments realistically need. In the end I elected that the best path was to have our security plan permit inbound connectivity from the DMZ for log traffic (via SSL) and puppet agent to master communication. While it was a risk we could reasonably bound and manage the security requirements, and the folks we worked with for audit preparation were happy that this was an acceptable risk when tightly controlled. [...]> I understand that fine, but we use facts quite a bit to get state > information, so the traditional part of the client server/model where facts > are shipped back from the client to the puppet server is missing. > > How do people get around the "common" rule that DMZ servers should not > initiate network connections back to the internal network? Should we have a > puppet server in the DMZ?If I couldn''t have the DMZ talk to my central master then, yes, I would deploy a second master to the DMZ and use that to manage things. (Depending on how you architect the DMZ you might find it attractive to use as the sole master, or not. We had the capability to "DMZ" any machine to a VLAN, so there was no reduction in cross-host security for doing this. :) We found that the utility of dynamic updates and facts, plus stored configuration, was worth the risk; overall they made it much easier to control, manage, and secure the systems, and so meet our overall security goals. You might ask, if there are concerns, what security analysis is required to get approval for puppet from the security teams. Typically this turns out to be pretty easy, in my experience. Regards, Daniel Now you tell us that you have a SECRET network, of course, and I sympathise and think of transparent ducting. ;) -- ⎋ Puppet Labs Developer – http://puppetlabs.com ✉ Daniel Pittman <daniel@puppetlabs.com> ✆ Contact me via gtalk, email, or phone: +1 (877) 575-9775 ♲ Made with 100 percent post-consumer electrons -- 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, On Feb 11, 2011, at 07:25, John Warburton wrote:> Does anyone have any experiences with puppet in the DMZ they can share? > > At my puppet master training (Hi Hunter), it was mentioned some people compile their catalogs inside, then ship them out to servers in the DMZ to be applied. > > I understand that fine, but we use facts quite a bit to get state information, so the traditional part of the client server/model where facts are shipped back from the client to the puppet server is missing. > > How do people get around the "common" rule that DMZ servers should not initiate network connections back to the internal network? Should we have a puppet server in the DMZ? >Another approach is to use SSH tunnels. Use autossh to initiate SSH connections from your puppetmaster to each client. The SSH tunnels open port 8140 on localhost on the client, allowing puppet on the client to tunnel back to the master. Not the most efficient approach, but easier to implement than a slave master. I have about 50 DMZ clients running this way. The gist of the autossh startup would be something like this monitorport=20000 foreach clientname in $DMZclients; do /usr/bin/autossh -M $monitorport -f -R localhost:8140:localhost:8140 -N -n -x $clientname monitorport=`expr $monitorport + 10` done Pointing your clients at localhost:8140 can be done in either puppet.conf or by adding an entry to /etc/hosts. Cheers, -Thorsten -- 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 can put a puppet server in the DMZ that you deploy puppet manifest changes to via SSH, then only allow 8140 access to the dmz boxes. I would say shipping catalogs out there is sort of overkill. You can also make this master use a separate CA, etc. I think a few simple measures like this would make it as secure as trying to do some esoteric ''ultra-secure'' techniques. On 02/11/2011 01:25 AM, John Warburton wrote:> Curse GW Bush and his ''Axis of Evil'' - my google searches are > contaminated with hits to Korea, and other such fun... > > Does anyone have any experiences with puppet in the DMZ they can share? > > At my puppet master training (Hi Hunter), it was mentioned some people > compile their catalogs inside, then ship them out to servers in the > DMZ to be applied. > > I understand that fine, but we use facts quite a bit to get state > information, so the traditional part of the client server/model where > facts are shipped back from the client to the puppet server is missing. > > How do people get around the "common" rule that DMZ servers should not > initiate network connections back to the internal network? Should we > have a puppet server in the DMZ? > > Thanks > > John > -- > 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.-- Joe McDonagh AIM: YoosingYoonickz IRC: joe-mac on freenode "When the going gets weird, the weird turn pro." -- 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 Fri, Feb 11, 2011 at 00:40, Thorsten Biel <Thorsten.Biel@porsche.de> wrote:> On Feb 11, 2011, at 07:25, John Warburton wrote: > >> Does anyone have any experiences with puppet in the DMZ they can share?[…]>> How do people get around the "common" rule that DMZ servers should not initiate network connections back to the internal network? Should we have a puppet server in the DMZ? > > Another approach is to use SSH tunnels. Use autossh to initiate SSH > connections from your puppetmaster to each client. > > The SSH tunnels open port 8140 on localhost on the client, allowing puppet on the > client to tunnel back to the master. > > Not the most efficient approach, but easier to implement than a slave master. > I have about 50 DMZ clients running this way.I am rather surprised: wouldn''t your network security folks and auditors go absolutely ape when they discovered that you had punched a hole through their firewall to allow connections from the DMZ to a secure network without going through the appropriate security analysis process? Anyway, I guess my point is that while this would probably work I can''t really see why it would bring any benefit compared to just punching the hole through the firewall directly: Puppet uses SSL secured communication, and validates the identity at both ends, so you have no more or less exposure than with this mechanism, so far as I can see? Regards, Daniel -- ⎋ Puppet Labs Developer – http://puppetlabs.com ✉ Daniel Pittman <daniel@puppetlabs.com> ✆ Contact me via gtalk, email, or phone: +1 (877) 575-9775 ♲ Made with 100 percent post-consumer electrons -- 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 Feb 11, 2011, at 20:00, Daniel Pittman wrote:> On Fri, Feb 11, 2011 at 00:40, Thorsten Biel <Thorsten.Biel@porsche.de> wrote: >> On Feb 11, 2011, at 07:25, John Warburton wrote: >> >>> How do people get around the "common" rule that DMZ servers should not initiate network connections back to the internal network? Should we have a puppet server in the DMZ? >> >> Another approach is to use SSH tunnels. Use autossh to initiate SSH >> connections from your puppetmaster to each client. >> > > I am rather surprised: wouldn''t your network security folks and > auditors go absolutely ape when they discovered that you had punched a > hole through their firewall to allow connections from the DMZ to a > secure network without going through the appropriate security analysis > process?That''s where IT and medicine are sometimes similar : ask 3 experts and you get 3 different recommendations. :) But to get back to the point: no, they aren''t going ape. Why should they?> Anyway, I guess my point is that while this would probably work I > can''t really see why it would bring any benefit compared to just > punching the hole through the firewall directly: Puppet uses SSL > secured communication, and validates the identity at both ends, so you > have no more or less exposure than with this mechanism, so far as I > can see?It boils down to the question of whether you allow DMZ servers to initiate connections into the internal (secure) zone or not. As this could turn into a lengthy mail exchange, how about we discuss it at Puppet Camp Europe? Cheers, Thorsten -- 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 Mon, Feb 14, 2011 at 01:35, Thorsten Biel <Thorsten.Biel@porsche.de> wrote:> On Feb 11, 2011, at 20:00, Daniel Pittman wrote:=>> On Fri, Feb 11, 2011 at 00:40, Thorsten Biel <Thorsten.Biel@porsche.de> wrote:>>> On Feb 11, 2011, at 07:25, John Warburton wrote: >>> >>>> How do people get around the "common" rule that DMZ servers should not initiate network connections back to the internal network? Should we have a puppet server in the DMZ? >>> >>> Another approach is to use SSH tunnels. Use autossh to initiate SSH >>> connections from your puppetmaster to each client. >> >> I am rather surprised: wouldn''t your network security folks and >> auditors go absolutely ape when they discovered that you had punched a >> hole through their firewall to allow connections from the DMZ to a >> secure network without going through the appropriate security analysis >> process? > > That''s where IT and medicine are sometimes similar : ask 3 experts and > you get 3 different recommendations. :) > > But to get back to the point: no, they aren''t going ape. Why should they?Because using SSH to create a tunnel that allows servers in the DMZ to connect to the internal network is often considered a problem. :) […]> It boils down to the question of whether you allow DMZ servers to initiate > connections into the internal (secure) zone or not.I think we are in agreement there, and I agree that this is probably the end of the value in the discussion. So, having explained why I see the issue I am happy to, if we still do, agree to disagree. :) Daniel -- ⎋ Puppet Labs Developer – http://puppetlabs.com ✉ Daniel Pittman <daniel@puppetlabs.com> ✆ Contact me via gtalk, email, or phone: +1 (877) 575-9775 ♲ Made with 100 percent post-consumer electrons -- 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.