Re: [Puppet Users] puppet in the dmz?

[Rob Nelson]

Jason,

Security methodology for DMZs varies quite a bit for different companies.
In some, there are ZERO connections from DMZ to LAN, in others it's just
restricted to acceptable levels of risk. With Puppet, there's no full-blown
Push method I'm aware of that you can use (you could possibly combine some
sort of LAN->DMZ push of code and run `puppet apply` as a scheduled
task/cronjob, but getting code to nodes isn't part of Puppet).

I think the most reasonable compromises that maintain the `puppet agent`
workflow you likely use are either A) placing an additional master in the
DMZ and have the agents connect to it or B) have the agents connect to the
existing master in the LAN on port 8140/tcp. In scenario A, you could push
code to the master through Code Manager (PE) or use r10k to fetch it from
appropriate sources - this would be your one DMZ->LAN connection - and the
agent traffic never hits the LAN. In scenario B, all the agents do have to
contact the LAN, but they do it on a single port and using SSL, mitigating
your risk.

A (IMO) less secure scenario C that some companies entertain would be a
multi-homed node, in this case your DMZ master having a second connection
to the LAN so it doesn't go through the firewall, but I dislike that. It
maintains the letter of the rule of no sessions from the DMZ communicating
through the firewall to the LAN, but violates the spirit of the rule by
creating a bridge between the segments without the firewall policy to
minimize risk.

Most places I've been at would accept the risk of agents talking to the
master only (scenario B); a few would prefer an additional DMZ master and
accept the overhead (scenario A); only one would take scenario C and it's
no coincidence that I quit that company in a hurry :)

Hope that helps.


Rob Nelson
rnels...@gmail.com

On Wed, Aug 23, 2017 at 2:20 PM, Jason McMahan 
wrote:

> Good day,
> We are looking at managing our infrastructure in the dmz as we do our
> internal nodes with puppet.
> We are running multiple masters with foreman as our enc. R10k ensure the
> manifests on all masters are updated regularly.
>
> Does anyone have suggestion to integrate the dmz into our current layout
> as well as ensure security?
>
> We have mainly windows machines, with a handful of linux ones in the dmz.
>
> Thoughts have been, place a master in the dmz all agents talk to that
> master. But then what should we do? Have a connection to puppetdb internal?
> Create a copy of what we have internal in the dmz? That is the least
> favorable option.
>
> Any help of input is greatly appreciated.
>
> Thank you
>
> --
> 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/3abd0b97-ed16-407c-98a1-4476be75358a%40googlegroups.com
> 
> .
> 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_JKeu%3DDMatJHFncxyDA07TXLgojEpFZN4NeL6AxktzFA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] puppet in the dmz?

[Jason McMahan]

Good day,
We are looking at managing our infrastructure in the dmz as we do our 
internal nodes with puppet.
We are running multiple masters with foreman as our enc. R10k ensure the 
manifests on all masters are updated regularly.

Does anyone have suggestion to integrate the dmz into our current layout as 
well as ensure security?

We have mainly windows machines, with a handful of linux ones in the dmz.

Thoughts have been, place a master in the dmz all agents talk to that 
master. But then what should we do? Have a connection to puppetdb internal? 
Create a copy of what we have internal in the dmz? That is the least 
favorable option.

Any help of input is greatly appreciated.

Thank you

-- 
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/3abd0b97-ed16-407c-98a1-4476be75358a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

RE: [Puppet Users] Puppet in the DMZ via proxy

[Kinzel, David]

>On Thu, Oct 20, 2011 at 12:46 PM, Geoff Galitz 
> 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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Puppet in the DMZ via proxy

[Jörgen Maas]

On Thu, Oct 20, 2011 at 12:46 PM, Geoff Galitz  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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Puppet in the DMZ via proxy

[Geoff Galitz]

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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Puppet in the DMZ

[Daniel Pittman]

On Mon, Feb 14, 2011 at 01:35, Thorsten Biel  wrote:
> On Feb 11, 2011, at 20:00, Daniel Pittman wrote:
=>> On Fri, Feb 11, 2011 at 00:40, Thorsten Biel
 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 
✆ 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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Puppet in the DMZ

[Thorsten Biel]

On Feb 11, 2011, at 20:00, Daniel Pittman wrote:

> On Fri, Feb 11, 2011 at 00:40, Thorsten Biel  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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Puppet in the DMZ

[Daniel Pittman]

On Fri, Feb 11, 2011 at 00:40, Thorsten Biel  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 
✆ 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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Puppet in the DMZ

[Joe McDonagh]

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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Puppet in the DMZ

[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=2
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Puppet in the DMZ

[Daniel Pittman]

On Thu, Feb 10, 2011 at 22:25, John Warburton  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 
✆ 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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Puppet in the DMZ

[Patrick]

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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Puppet in the DMZ

[John Warburton]

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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.