Same certificate on multiple identical machines ?
julien
In our platform we have a lot of machines in which the system is a
single disk image loaded on RAM from PXE.
The problem is quite simple : if I install puppetd on the image, I
will end up using the same certificate for 100 different servers with
different names (the hostname is setup at boot time from dhcp) and I
guess the puppetmaster won't allow that.
In other words : what should I do to create a hundred nodes with the
same certificate ?
Dan Bode
Hi list,
In our platform we have a lot of machines in which the system is a
single disk image loaded on RAM from PXE.
The problem is quite simple : if I install puppetd on the image, I
will end up using the same certificate for 100 different servers with
different names (the hostname is setup at boot time from dhcp) and I
guess the puppetmaster won't allow that.
why cant you just use a different certificate for each host?
In other words : what should I do to create a hundred nodes with the
same certificate ?
I don't the exact reason why, but this is not a recommended setup.
--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To post to this group, send email to puppet...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Patrick
On May 31, 2010, at 6:41 AM, julien wrote:
> The problem is quite simple : if I install puppetd on the image, I
> will end up using the same certificate for 100 different servers with
> different names (the hostname is setup at boot time from dhcp) and I
> guess the puppetmaster won't allow that.
I think the puppetmaster will allow it, but it's usually not recommended.
> In other words : what should I do to create a hundred nodes with the
> same certificate ?
You should just be able to get the certificate signed on one of them and then put the whole /var/lib/puppet directory in the image. Remember that with this method, any computer that can access the PXE server can pretend to be one of those servers to the puppetmaster.
It'll also be annoying to set different configurations on those servers because they have the same cert name. I don't know if this is a problem.
Matt Juszczak
> then put the whole /var/lib/puppet directory in the image. Remember
> that with this method, any computer that can access the PXE server can
> pretend to be one of those servers to the puppetmaster.
>
> It'll also be annoying to set different configurations on those servers
> because they have the same cert name. I don't know if this is a
> problem.
Why not just not launch puppet in the PXE image, but add it to
/etc/rc.conf and/or /sbin/chkconfig, so when the PXE image servers boot
for the first time, they'll generate a certificate request and you can
just sign it on the puppetmaster?
I would keep individual certificate signing as a manual process - it's
your final checkpoint to make sure the server really is who you think it
is :)
Patrick
These servers only exist in RAM, so when they shutdown, all data is lost. Julien also said that there's over a hundred of them. If you are manually signing every time they reboot, you probably won't be diligent enough to catch an impostor that can use the PXE server. At that point, you might as well just put the cert in the PXE image. I don't like my solution, but I think it's better than manual signing unless you have persistent storage on the puppet clients.
Matt Juszczak
> lost. Julien also said that there's over a hundred of them. If you are
> manually signing every time they reboot, you probably won't be diligent
> enough to catch an impostor that can use the PXE server. At that point,
> you might as well just put the cert in the PXE image. I don't like my
> solution, but I think it's better than manual signing unless you have
> persistent storage on the puppet clients.
Ah, I missed the dynamic part. I agree, manually signing hundreds of
servers would be annoying. Unless you scripted it and had it email you
when it signed a cert... at least you'd have some sort of trail. If you
get an email at 2 AM in the morning that a new server cert was signed...
well, that may not be a good thing :)
julien
You got the point, when the servers reboot they get back to their
original state.
I will try to integrate a certificate in the image. The servers are
not meant to restart very often but when they do, they would need to
be updated by puppet right away.
I guess puppet won't let me do this because the hostname will change
and I think it's tied to the certificate.
Perhaps the principle of disk images at boot time is not very
compatible with puppet "spirit". After all I could configure the image
correctly and just deploy it. But I would like to use puppet to
"enforce" my configuration principles in case of human errors, bugs,
etc...
Patrick
On Jun 1, 2010, at 1:28 AM, julien wrote:
> Thanks for your quick answers.
>
> You got the point, when the servers reboot they get back to their
> original state.
>
> I will try to integrate a certificate in the image. The servers are
> not meant to restart very often but when they do, they would need to
> be updated by puppet right away.
> I guess puppet won't let me do this because the hostname will change
> and I think it's tied to the certificate.
>
> Perhaps the principle of disk images at boot time is not very
> compatible with puppet "spirit". After all I could configure the image
> correctly and just deploy it. But I would like to use puppet to
> "enforce" my configuration principles in case of human errors, bugs,
> etc...
You say you want puppet to "just work" when you restart. There's two real options:
A) Put the certificate in the image.
B) Setup auto-sign
*) Technically you could also launch a script from the client computer that executes puppetca on the server, but that's like "B" but even worse.
A gives you less flexibility because every client has the same name, but more security because only computers with access to the PXE server can get the certificate.
B gives you more flexibility because you can tell the computers apart because each has a different cert name, but now any computer that can connect to the puppet master can impersonate a client.
If you pick A, anyone with access to the PXE server and the puppetmaster can impersonate any client and get all the client's configuration that's pushed with puppet.
If you pick B, anyone with access to the puppetmaster can impersonate any client and get all the client's configuration that's pushed with puppet.
Ask yourself:
*) Do you trust the clients?
*) Do you trust the network they are on?
*) What information does the puppetmaster give out, and does is matter if other computers on the local network get it?
>
> On May 31, 10:34 pm, Matt Juszczak <m...@atopia.net> wrote:
>>> These servers only exist in RAM, so when they shutdown, all data is
>>> lost. Julien also said that there's over a hundred of them. If you are
>>> manually signing every time they reboot, you probably won't be diligent
>>> enough to catch an impostor that can use the PXE server. At that point,
>>> you might as well just put the cert in the PXE image. I don't like my
>>> solution, but I think it's better than manual signing unless you have
>>> persistent storage on the puppet clients.
>>
>> Ah, I missed the dynamic part. I agree, manually signing hundreds of
>> servers would be annoying. Unless you scripted it and had it email you
>> when it signed a cert... at least you'd have some sort of trail. If you
>> get an email at 2 AM in the morning that a new server cert was signed...
>> well, that may not be a good thing :)
>
Michael Dodwell
state, but does that image/machine ever get reused?
My point being if your going to reuse machines keeping individual
certificates could be useful. To enable this you could just nfs mount
a share that new certificates could be created in, and 'old'
certificates could be loaded from. You should just have to mount /var/
lib/puppet/ssl/ and after creating the required sub-directories new
machines will auto generate certificates and reused machines would use
existing certificates. That way you should have some control over
signing.
--MD
Patrick
*) Do something pretty complicated so the server gives diffierent mounts t each computer, orwith different mounts
or
*) Give every machine access to all the other machine's certificates, and store all the credentials for the NFS server in the PXE server where anyone can get them.
I have no idea how to do the first, and the second doesn't sound very good to me. Also, you need to trust the local network anyway. After all, anyone on that network can impersonate the DHCP and PXE server to hijack a PXE client.
Trevor Vaughan
Hash: SHA1
How sensitive is the information you're pushing out?
If it's not sensitive, I would list all valid hosts in autosign.conf and
blow the certs away with a hourly cron job on the server.
It seems silly, but it shouldn't add *too* much overhead in general.
If your puppet server is also your tftp server, you could spawn a
puppetca --clean <hostname> from the tftp logs but you have a potential
race condition in that case.
If they are all *truly* identical from a Puppet point of view, you could
have an extremely long list of alternate DNS names in your pre-generated
Puppet client cert and just use the same cert for everyone.
I'm not sure what the limits are on this as I've never tried it for more
than a dozen or so hostnames.
Trevor
- --
Trevor Vaughan
Vice President, Onyx Point, Inc.
email: tvau...@onyxpoint.com
phone: 410-541-ONYX (6699)
pgp: 0x6C701E94
- -- This account not approved for unencrypted sensitive information --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEARECAAYFAkwFp8YACgkQyWMIJmxwHpSy2gCcCcgz+tvn+Ukgq8JsHiSjfU2v
irkAoKwz74h3qPcVdJ4Vt3AST/PDs9F5
=HoxJ
-----END PGP SIGNATURE-----
Patrick
On Jun 1, 2010, at 5:37 PM, Trevor Vaughan wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> How sensitive is the information you're pushing out?
>
> If it's not sensitive, I would list all valid hosts in autosign.conf and
> blow the certs away with a hourly cron job on the server.
>
> It seems silly, but it shouldn't add *too* much overhead in general.
>
> If your puppet server is also your tftp server, you could spawn a
> puppetca --clean <hostname> from the tftp logs but you have a potential
> race condition in that case.
>
> If they are all *truly* identical from a Puppet point of view, you could
> have an extremely long list of alternate DNS names in your pre-generated
> Puppet client cert and just use the same cert for everyone.
In my experience, after the certificate is on the client, the DNS name of the client doesn't matter. I think it's because puppet ignores the DNS name of the client and just uses the certificate name.
> <tvaughan.vcf>
Игорь Тиунов
Hi Guys!
The certificat of the client itself is not used for communication to puppet-master. Agent use for this its private key that can be schared between your immutable PXE hosts. You cat just rename (m.b. in rc.local) this private key during machine startup to correspond to new hostname of server and than start puppet-agent service. In this case puppet agent will use this shared private key. Old servers will continue to communicate with the master as if nothing had happened after a reboot. New servers will receive a new certificate. But each certificate will correspond to a single private key. Although they will have different Canonical Name (CN == hostname).
понедельник, 31 мая 2010 г., 16:41:55 UTC+3 пользователь julien написал: