Hi. We''re thinking of ways to get our DMZ nodes managed by puppet, and in the absence of a full-fledged push model we are thinking about pointing puppets in our DMZ network at a bastion host running squid to proxy back to our puppet master. In this scenario, the single bastion host would have an ACL allowing access through our inner firewall to the master, but the various nodes would have no direct access. That would give us a nice choke point that we can monitor and isolate if needed. We''d still get all of our reporting functions, too. Has anyone tried something along these lines? Any opinions? Thanks. -- 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, Oct 20, 2011 at 12:46 PM, Geoff Galitz <ggalitz@shutterstock.com> wrote:> > We''re thinking of ways to get our DMZ nodes managed by puppet, and in > the absence of a full-fledged push model we are thinking about > pointing puppets in our DMZ network at a bastion host running squid to > proxy back to our puppet master. > > In this scenario, the single bastion host would have an ACL allowing > access through our inner firewall to the master, but the various nodes > would have no direct access. That would give us a nice choke point > that we can monitor and isolate if needed. We''d still get all of our > reporting functions, too. > > > Has anyone tried something along these lines? Any opinions? >We have this kind of setup in production, basically all managed objects are only allowed to connect through a squid proxy. This works without any problems at all. -- Grtz, Jörgen Maas -- 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, Oct 20, 2011 at 12:46 PM, Geoff Galitz ><ggalitz@shutterstock.com> wrote: >> >> We''re thinking of ways to get our DMZ nodes managed by puppet, and in >> the absence of a full-fledged push model we are thinking about >> pointing puppets in our DMZ network at a bastion host >running squid to >> proxy back to our puppet master. >> >> In this scenario, the single bastion host would have an ACL allowing >> access through our inner firewall to the master, but the >various nodes >> would have no direct access. That would give us a nice choke point >> that we can monitor and isolate if needed. We''d still get all of our >> reporting functions, too. >> >> >> Has anyone tried something along these lines? Any opinions? >>We have an allow-list of hosts which connect to a NAT IP that gets forwarded internally. This is a simpler setup than having a proxy do it. This email communication and any files transmitted with it may contain confidential and or proprietary information and is provided for the use of the intended recipient only. Any review, retransmission or dissemination of this information by anyone other than the intended recipient is prohibited. If you receive this email in error, please contact the sender and delete this communication and any copies immediately. Thank you. http://www.encana.com -- 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.
I also had such a scheme, but having the puppetmaster on an internal private IP network, not even a DMZ. Puppet runs were triggered, there was no puppet client daemon or crontabed runs. server with Puppet client is on interent with public IP Local intranet: Puppetmaster a Squid proxy When i want to puppetize a machine, from my local workstation in the same network as the puppetmaster and squid, i connect with ssh creating a tunnel -L 3128:squidserver:3128 . Once logged, i launched puppet --server puppetmaster.local --test --http_proxy_host localhost --http_proxy_port 3128 -> The Puppet client connects to the intranet proxy though the tunnel. The proxy can route to the puppetmaster. I keep the tunnel open just for the time of the puppetize On 20 oct, 21:14, "Kinzel, David" <David.Kin...@encana.com> wrote:> >On Thu, Oct 20, 2011 at 12:46 PM, Geoff Galitz > ><ggal...@shutterstock.com> wrote: > > >> We''re thinking of ways to get our DMZ nodes managed by puppet, and in > >> the absence of a full-fledged push model we are thinking about > >> pointing puppets in our DMZ network at a bastion host > >running squid to > >> proxy back to our puppet master. > > >> In this scenario, the single bastion host would have an ACL allowing > >> access through our inner firewall to the master, but the > >various nodes > >> would have no direct access. That would give us a nice choke point > >> that we can monitor and isolate if needed. We''d still get all of our > >> reporting functions, too. > > >> Has anyone tried something along these lines? Any opinions? > > We have an allow-list of hosts which connect to a NAT IP that gets forwarded internally. This is a simpler setup than having a proxy do it. > > This email communication and any files transmitted with it may contain > confidential and or proprietary information and is provided for the use of the > intended recipient only. Any review, retransmission or dissemination of this > information by anyone other than the intended recipient is prohibited. If you > receive this email in error, please contact the sender and delete this > communication and any copies immediately. Thank you. > > http://www.encana.com-- 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.