Exposing master to the public internet

739 views
Skip to first unread message

Nik Haldimann

unread,
Jul 2, 2015, 4:06:07 PM7/2/15
to puppet...@googlegroups.com
Hi

I have a fleet of headless devices to manage that are going to be deployed all over the place on various networks but connected to the public internet. I'm evaluating if it would make sense to manage them through puppet. I am able to run the puppet agent on the devices and I seem to be able to do things I would want to do, so on the surface this seems like a good idea.

However, my impression is that a puppet master is usually deployed within a private networks (e.g., internal to a data center or as part of a private VPC subnet on AWS). For my use case I would have to open the master to the public internet. What are the implications of this? Is this recommended or not? Are there specific settings I should be watching out for to make this secure?

Nik

Craig Dunn

unread,
Jul 3, 2015, 3:31:02 AM7/3/15
to puppet...@googlegroups.com
On Thu, Jul 2, 2015 at 9:51 PM, Nik Haldimann <n...@placemeter.com> wrote:

> However, my impression is that a puppet master is usually deployed within a
> private networks (e.g., internal to a data center or as part of a private
> VPC subnet on AWS). For my use case I would have to open the master to the
> public internet. What are the implications of this? Is this recommended or
> not? Are there specific settings I should be watching out for to make this
> secure?

I can't think of any reason why it would be a bad idea to run Puppet
over a public network - The SSL features alone actually make it quite
suitable for this type of set up. You can also tweak auth.conf to
further secure it. Two things which I would advise though are 1)
Don't autosign your certs, and 2) don't trust any facts from the
agent, if using things like certname in hiera.yaml or elsewhere always
source the value from a trusted facts
(https://docs.puppetlabs.com/puppet/latest/reference/lang_facts_and_builtin_vars.html#trusted-facts)

Craig

Don't autosign your certs

Chris Spence

unread,
Jul 3, 2015, 10:27:41 AM7/3/15
to puppet...@googlegroups.com
Without firewalling you're asking for trouble though if you ask me.

Take for example the certificate endpoint - the security model requires that the certificate request endpoint be open to unauthenticated access.  There are obvious denial of service possibilities there (fill up the disk with crufty requests, for example).

I'd find some way of running without a master, or if I had to run one on the public internet, implement some security at the network to filter requests.

Tom Limoncelli

unread,
Jul 6, 2015, 7:32:13 AM7/6/15
to puppet...@googlegroups.com
Google does this on a massive scale for the laptops they give to employees.  Many of the details are in http://research.google.com/pubs/pub43231.html

The key points are:
1.  SSL only.  All else is firewalled off.  (external clients actually talk to a load balancer that is locked down and only forwards SSL-authenticated connections to the master).
2.  Don't autosign your certs.
3.  When you sign certs, actually check the fingerprints
4.  The server cert AND the client cert must be signed (puppet cert takes care of that for you).

Tom
(not a google employee, not speaking for google)


--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/081d9674-434b-4057-b2b7-1c02ecb91d40%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
Email: t...@whatexit.org    Work: tlimo...@StackOverflow.com
Skype: YesThatTom
Blog:  http://EverythingSysadmin.com
Reply all
Reply to author
Forward
0 new messages