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, [email protected]
>>> 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 [email protected].
>>> 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 [email protected].
>> 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 [email protected].
> 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 [email protected].
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