In our environment, the FQDN is not stable, but the certname is. In the
past, I've simply tracked all nodes (in Puppet Dashboard) via the
certname.
In Foreman 1.6.0, here's the behavior I've observed:
Node with certname X and FQDN Y does a puppet run. In The Foreman, the
node shows up as Y (under All Hosts). When you click on it, it has the
certname = X value.
Now, the FQDN on this Node changes to Z. It performs a puppet run. In The
Foreman, the node shows up as Y (still). When you click on it, it has the
certname = X value.
In the rare case the certname/CN needs to change, this is what happens:
certname/CN changes to Q:
If the hostname (FQDN) is still Y when it performs a puppet run, Foreman
will update the certname for Y from X to Q. It apparently correllates the
hostname (FQDN) and uses that as identity. I believe that's from this line
in managed.rb:
return Host.new, true if host.nil?
# if we were given a certname but found the Host by hostname we should
update the certname
host.certname = certname if certname.present?
What is the reasoning behind this? To me, the certname (CN) should be the
only identity mechanism, and there should be no case where the hostname
(FQDN) can be used for identity to Puppet/Foreman. I could think of a
security issue where a new certificate is signed (cn=newnode) and the
malicious system administrator (insider thread) changes the system's
hostname/FQDN to a system that's already in Puppet/Foreman (let's call it
radiusserver). When this new system talks to Foreman for the first time,
Foreman will update the entry for Host "radiusserver" with what it thinks
is its new certname (cn=newnode), and will provide manifests to newnode as
if it were radiusserver (that is bad).
Am I missing something obvious?