Disabling Certificates
Derek J. Balling
Peter De Cleyn
--
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.
James Turnbull
> Hi Derek,
>
> In our setup, the certificates pose also more problems than they add
> functionality. I would love to hear of a solution to get rid of the
> certificates, but until now I did not find or heard of any solution.
>
> Peter
> On 11 Nov 2010, at 04:42, Derek J. Balling <dr...@megacity.org
>
>> Has anyone had any luck in actually /disabling/ certificates entirely.
>> Just trust the hostname you get from DNS and treat that info as
>> authoritative.
>>
>> I'm in the Puppet BoF @ LISA, and (essentially) was told that's never
>> going to happen, even though I have *no* need for the security that
>> the certificates theoretically provide and they get in my way far more
>> often than any alleged "help".
>>
>> Has anyone managed to just obliterate the whole certificate-nightmare
>> from Puppet? Is there anyone else who thinks they add way more
>> complications than they are worth?
For a lot of environments the security introduced with SSL is crucial to
them using Puppet, for example there is no way a financial is going to
run Puppet with appropriate encryption and authentication.
That being said we have discussed alternative mechanisms - see
http://projects.puppetlabs.com/issues/3958 for example - but this is not
something we're currently actively pursuing.
You're welcome to put your thoughts into that ticket or contact us
directly if you'd like to pay us to develop the feature.
Regards
James
--
Puppet Labs - http://www.puppetlabs.com
C: 503-734-8571
donavan
From your comment in #3958 I think autosign[1] with "*.domain.tld"
would work for you. There are more complicated methods of supporting
transient hosts, such as in "the cloud", where not even the hostname
is consistent. I suspect that may be more work than you're looking
for.
[1] http://projects.puppetlabs.com/projects/puppet/wiki/Certificates_And_Security
Derek J. Balling
On Nov 11, 2010, at 6:26 PM, donavan wrote:
> From your comment in #3958 I think autosign[1] with "*.domain.tld"
> would work for you.
Nope. Because "autosign" doesn't also "auto-overwrite".
- New Host "foo001.domain.tld" is created
- Certs are exchanged for foo001 with the puppetmaster, life is good, autosigned
- Host foo001.domain.tld is retired
- Replacement Host "foo001.domain.tld" is created
- foo001 tries to talk to puppetmaster, presenting brand new certs. They don't match what the master has for that host. It tells foo001 to pound-sand.
At that point, I have to manually log into the CA and clean out the certificates for foo001. I also have to go out to foo001, and blow away all ITS certs, since it's been given a cert it has no idea what to do with.
It's just ugly. Like I said in my ticket notes, I'll concede that for some people, it's a necessity, but there's clearly also a set of people for whom it is just unnecessary pain and suffering.
Thomas Bendler
Nope. Because "autosign" doesn't also "auto-overwrite".
- New Host "foo001.domain.tld" is created
- Certs are exchanged for foo001 with the puppetmaster, life is good, autosigned
- Host foo001.domain.tld is retired
- Replacement Host "foo001.domain.tld" is created
- foo001 tries to talk to puppetmaster, presenting brand new certs. They don't match what the master has for that host. It tells foo001 to pound-sand.
At that point, I have to manually log into the CA and clean out the certificates for foo001. I also have to go out to foo001, and blow away all ITS certs, since it's been given a cert it has no idea what to do with.
removing the certificate is part of the retirement process, as well as removing the DNS entry, free up the IP in the CMDB, remove hardware from rack and what else needs to be done when a box is retired. Nearly all of this stuff could be scripted except the removal from the rack.
Kind regards, Thomas
James Turnbull
> It's just ugly. Like I said in my ticket notes, I'll concede that for
> some people, it's a necessity, but there's clearly also a set of
> people for whom it is just unnecessary pain and suffering.
>
It's been my experience that SSL (or the requirement for some form of
this type of security even if they disliked SSL) is actually required by
the vast majority of people using Puppet.
Certainly if you have any security requirements you need some kind of
encryption/authentication mechanism. Without one - anyone can
compromise your configuration and a daemon generally running with root
privileges. But I concede there might be shops out there who don't care
about this issue.
I doubt it will change in a hurry - removing SSL from Puppet or
abstracting it into a module as part of a refactor of security would be
a large undertaking.
Regards
James Turnbull
binaryred
I agree with you that the certificates are unnecessary for some
people, myself included. Since we're behind a large corporate
firewall, we don't need this type of security for in house
management. As we upgrade our engineers workstations, the new
workstation almost always has the same name as the old, and we get the
same issue. I've found that I can just move the certificate on the
puppet master out of the default directory with a cronjob (I move them
elsewhere instead of deleting them), that way, when we upgrade the
workstation, it just submits a new certificate request. This seems to
work well for us, and doesn't cause any problems with the workstations
connecting to the master.
Jason
Nigel Kersten
>
> On Nov 11, 2010, at 6:26 PM, donavan wrote:
>> From your comment in #3958 I think autosign[1] with "*.domain.tld"
>> would work for you.
>
> Nope. Because "autosign" doesn't also "auto-overwrite".
Actually it has meant that in some versions, but it wasn't
intentional. 0.25.x up to 0.25.5 would overwrite.
"Add a flag to make puppet ca behavior on receipt of duplicate request
configurable"
http://projects.puppetlabs.com/issues/3360
That's the bug you want to track. We need to make it configurable so
you can indeed specify that autosign means overwrite if that's what
you want.
In the meantime if you really want to get this behavior, you can set
up a regular cron job on the CA to discard the existing client info so
you can always count on overwrite working.
Another approach is to use a randomly generated certname. I've used
UUIDs in the past to achieve this.
This may not be appropriate for your environment, but note that if you
really need to get a mapping from such random certnames to hostnames,
your external node classifier can look inside the fact cache on the
puppetmaster to retrieve this info.
The fact cache is written to disk *before* the external node
classifier is consulted.
>
> - New Host "foo001.domain.tld" is created
> - Certs are exchanged for foo001 with the puppetmaster, life is good, autosigned
> - Host foo001.domain.tld is retired
> - Replacement Host "foo001.domain.tld" is created
> - foo001 tries to talk to puppetmaster, presenting brand new certs. They don't match what the master has for that host. It tells foo001 to pound-sand.
>
> At that point, I have to manually log into the CA and clean out the certificates for foo001. I also have to go out to foo001, and blow away all ITS certs, since it's been given a cert it has no idea what to do with.
>
> It's just ugly. Like I said in my ticket notes, I'll concede that for some people, it's a necessity, but there's clearly also a set of people for whom it is just unnecessary pain and suffering.
>
> --
> 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.
>
>
--
Nigel Kersten - Puppet Labs - http://www.puppetlabs.com