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


On 01/09/2014 11:57 PM, Jeff Bachtel wrote:
> 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
>
>> 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
>>  
>>
>> On 01/09/2014 04:05 PM, jcbollinger wrote:
>>>
>>>
>>> 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
>>>
>>> -- 
>>> 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/3c8f53f8-09a2-4bd8-8fa8-1986efdafeb3%40googlegroups.com.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>> -- 
>> 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/52CEBC6A.3070403%40cscs.ch.
>> For more options, visit https://groups.google.com/groups/opt_out.
>
> -- 
> 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/52CF2955.2000306%40bericotechnologies.com.
> For more options, visit https://groups.google.com/groups/opt_out.

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

Reply via email to