Puppet in the DMZ
John Warburton
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
Patrick
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.
Daniel Pittman
> 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 <dan...@puppetlabs.com>
✆ Contact me via gtalk, email, or phone: +1 (877) 575-9775
♲ Made with 100 percent post-consumer electrons
Thorsten Biel
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
Joe McDonagh
--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To post to this group, send email to puppet...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@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."
Daniel Pittman
> 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
Thorsten Biel
On Feb 11, 2011, at 20:00, Daniel Pittman wrote:
> On Fri, Feb 11, 2011 at 00:40, Thorsten Biel <Thorst...@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
Daniel Pittman
> On Feb 11, 2011, at 20:00, Daniel Pittman wrote:
<Thorst...@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. :)