Single certificate, multiple nodes... or image-based systems

368 views
Skip to first unread message

Pablo Fernandez

unread,
Jan 9, 2014, 4:42:44 AM1/9/14
to puppet...@googlegroups.com
Dear all,

We are thinking about the possibility of using Puppet in an image-based
cluster. The compute nodes would boot and load the whole image to a
ramdisk, where r/w access is granted afterwards.

Our idea is to have a sample compute node running puppet where to create
the image from, and periodically extract a new image from it. Nodes that
reboot, simply take that image, change the hostname and IP addresses,
and little more (typical in image-based systems). The nice thing about
this is that, since the source image is from a puppetized host, its
clones will be as well! So changes in the puppet configuration will be
applied immediately to the nodes.

Does it sound right? I currently foresee a problem with the puppet node
certificates: is it possible to use a generic certificate, to enable
trust between puppet server and clients, but having each node a
different fqdn and be treated by puppet as different hosts (including
PuppetDB entries)? I saw different facts for each: ::clientcert and
::fqdn, that gave me hopes.
Besides that, do you see any other problem with this type of deployment?
Does anybody have experience with something similar?

Thanks!
BR/Pablo

Jose Luis Ledesma

unread,
Jan 9, 2014, 5:22:34 AM1/9/14
to puppet...@googlegroups.com
You can use autosign for signing certificates.

Regards,

Andrey Kozichev

unread,
Jan 9, 2014, 6:16:35 AM1/9/14
to puppet...@googlegroups.com

Maybe look into running masterless to avoid problems with certs. Just run puppet apply on the new server.

--
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/52CE6F14.7060508%40cscs.ch.
For more options, visit https://groups.google.com/groups/opt_out.

Pablo Fernandez

unread,
Jan 9, 2014, 7:40:42 AM1/9/14
to puppet...@googlegroups.com
Thanks for your suggestions,

Running masterless is a bit too exotic, since we would like to use all those nice features that make a Puppet installation complete: specially hiera searches and PuppetDB. Modules, too, should be compatible with other clusters, so no big deviations can occur.

Enabling auto-sign, as Jose Luis suggested, may be a possibility. I have just checked myself if autosign works if the same node was already registered in the CA... but according to the documentation it does not look like it, not to mention the security issues that come with it.

Does the certificate name need to match the fqdn for puppet to allow connections?

Thanks!
BR/Pablo

Andrey Kozichev

unread,
Jan 9, 2014, 10:02:28 AM1/9/14
to puppet...@googlegroups.com

Autosign will be not enough, since if server has already signed - it will show cert mismatch.

you can trigger cert clean every time you reimage server.

jcbollinger

unread,
Jan 9, 2014, 10:05:10 AM1/9/14
to puppet...@googlegroups.com


On Thursday, January 9, 2014 6:40:42 AM UTC-6, pablo.f...@cscs.ch wrote:
Thanks for your suggestions,

Running masterless is a bit too exotic, since we would like to use all those nice features that make a Puppet installation complete: specially hiera searches and PuppetDB. Modules, too, should be compatible with other clusters, so no big deviations can occur.

Enabling auto-sign, as Jose Luis suggested, may be a possibility. I have just checked myself if autosign works if the same node was already registered in the CA... but according to the documentation it does not look like it, not to mention the security issues that come with it.

Does the certificate name need to match the fqdn for puppet to allow connections?



I'm not certain, but even if not, what you propose is dangerous.  The master uses the certificate presented by the agent not just to authorize the agent, but also to identify it.  If all your nodes present the same certificate to the master, then they all claim to be the same machine, which is a lie.  I don't foresee any specific failure scenarios associated with that, but it is unwise to mess with the system's underlying assumptions in such a way.


John

Pablo Fernandez

unread,
Jan 9, 2014, 10:12:42 AM1/9/14
to puppet...@googlegroups.com
I understand your point. I guess the SSL layer will render the request as illegitimate, but even if it doesn't, it may be playing with fire :)

Thanks all for your thoughts, let me then present this as a generic question: did anybody try puppet on image-based systems? It would be wonderful to get some first-hand hints.

Thanks again!
BR/Pablo
--
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.

Juan Sierra Pons

unread,
Jan 9, 2014, 10:17:06 AM1/9/14
to puppet...@googlegroups.com
2014/1/9 jcbollinger <John.Bo...@stjude.org>:
> --
> 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/3c8f53f8-09a2-4bd8-8fa8-1986efdafeb3%40googlegroups.com.
>
> For more options, visit https://groups.google.com/groups/opt_out.

Hi

Other Idea could be create the signed certificate on the masterserver
and then copy it to the image using scp, libguestfs-tools, etc.

You can have an idea looking the provisioningDO rakefile:
https://github.com/juasiepo/provisioningDO/blob/master/rakefile

Best regards

--------------------------------------------------------------------------------------
Juan Sierra Pons ju...@elsotanillo.net
Linux User Registered: #257202
Web: http://www.elsotanillo.net Git: http://www.github.com/juasiepo
GPG key = 0xA110F4FE
Key Fingerprint = DF53 7415 0936 244E 9B00 6E66 E934 3406 A110 F4FE
--------------------------------------------------------------------------------------

Andrey Kozichev

unread,
Jan 9, 2014, 12:16:55 PM1/9/14
to puppet...@googlegroups.com
not entirely image-based, when new server was booted for the first time:
 1. it made http call to puppetmaster with it's hostname to do puppet cert clean <hostname>
 2. do puppet run
 3. made HTTP call to do puppet cert sign

It was kind of autosign + in case of CERT already existed it was removed and re-generated

sure security is poor in this approach, but it can be limited to only build vlan.

Andrey




Jeff Bachtel

unread,
Jan 9, 2014, 5:57:25 PM1/9/14
to puppet...@googlegroups.com
On 01/09/2014 10:12 AM, Pablo Fernandez wrote:
I understand your point. I guess the SSL layer will render the request as illegitimate, but even if it doesn't, it may be playing with fire :)


No, actually it doesn't verify certname against fqdn or any such, so technically you could bake in a single cert for an image. It's a bad idea because the Puppet master is supposed to know the state of a node, and it can't in that case (facts associated with the node like fqdn and ip and mac addresses will be constantly churning).

I use Puppet on image-based systems. As part of the sysprep step (making the image generic for future spawning), I go and delete ssl certs from either /var/lib/puppet/ssl or the Windows equivalent. I make sure the agent is configured to hit the correct puppet master on first run, although I don't personally autosign.

With 3.4's autosign hooks, you can presumably configured a shared key between your puppet master and baked images such that a node signals that it should be issued a certificate on provision.

Jeff

Patrick Hemmer

unread,
Jan 9, 2014, 7:58:06 PM1/9/14
to puppet...@googlegroups.com


On Thursday, January 9, 2014 7:40:42 AM UTC-5, pablo.f...@cscs.ch wrote:
Thanks for your suggestions,

Running masterless is a bit too exotic, since we would like to use all those nice features that make a Puppet installation complete: specially hiera searches and PuppetDB. Modules, too, should be compatible with other clusters, so no big deviations can occur.

Enabling auto-sign, as Jose Luis suggested, may be a possibility. I have just checked myself if autosign works if the same node was already registered in the CA... but according to the documentation it does not look like it, not to mention the security issues that come with it.

I have hundreds of systems built off a single image, and we use autosigning to do it. Puppet 3.4.0 introduced policy based autosigning. Our image has a file which contains extra information to add to the certificate signing request. One of these bits of information is a secret key. The puppet CA server then has a script which authorizes autosigning any requests which contain a valid secret key.

-Patrick

Johan De Wit

unread,
Jan 10, 2014, 2:57:30 AM1/10/14
to puppet...@googlegroups.com
Maybe you could try something like this ?

https://gist.github.com/ahpook/1182243
--
Johan De Wit

Open Source Consultant

Red Hat Certified Engineer (805008667232363)
Puppet Certified Professional 2013 (PCP0000006)
_________________________________________________________

Open-Future Phone +32 (0)2/255 70 70
Zavelstraat 72 Fax +32 (0)2/255 70 71
3071 KORTENBERG Mobile +32 (0)474/42 40 73
BELGIUM http://www.open-future.be
_________________________________________________________


Next Events:
Puppet Fundamentals Training | http://www.open-future.be/puppet-fundamentals-training-4-till-6th-february
Puppet Intruction Course | http://www.open-future.be/puppet-introduction-course-7th-february
Zabbix Certified Training | http://www.open-future.be/zabbix-certified-training-10-till-12th-february
Zabbix for Large Environments Training | http://www.open-future.be/zabbix-large-environments-training-13-till-14th-february
Subscribe to our newsletter | http://eepurl.com/BUG8H

Pablo Fernandez

unread,
Jan 10, 2014, 4:34:11 AM1/10/14
to puppet...@googlegroups.com
Awesome!!

So, just to wrap it up taking all your answers together, we have two options:
- Individual certs using Puppet 3.4 policy based autosign feature (http://docs.puppetlabs.com/puppet/3/reference/ssl_autosign.html#policy-based-autosigning) and some custom "puppet cert clean <hn>" HTTP calls before running puppet upon reboot, or
- Single cert for all, making puppet node_name to be taken from node's facter, this way: https://gist.github.com/ahpook/1182243

Thanks a lot to everybody, this was really useful for us!
BR/Pablo
Reply all
Reply to author
Forward
0 new messages