PuppetCA and puppetca_hostname_whitelisting - conflicting config(s) when using the Puppet Modules to configure?

Support
1

Foreman 1.19.1
puppet-puppet 12.1.0
puppet-foreman_proxy 12.1.0

Using puppet-puppet, puppet-foreman_proxy, and puppet-foreman to configure my Foreman ENvironment. I’m running into issues where config(s) are directly conflicting.

If on my Dedicated Puppet CA I use (abbreviated config):
class {‘foreman_proxy’:
puppetca => true,
puppetca_split_configs => false,
puppet => false,
}
class {‘puppet’:
server => true,
server_ca => true,
autosign_entries => ["*.my.fqdn.com"]
}

It configures my autosign.conf correctly - as follows
[root@fmncanpw1 puppet]# cat autosign.conf
#
# Managed by Puppet
#
*.my.fqdn.com

HOWEVER - puppetca_hostname_whitelisting is also enabled. Which means any new host that is provisioned “adds its fqdn” to my autosign.conf This is mostly redundant from what I can tell, except now on the next puppet run on the CA server itself, it “removes” the host entry from autosign.conf and then “bounces” the puppetserver service. In my heavier build environments this is leading to intermittent build failures as the CA is “needlessly restarting” when new builds are requesting a certificate.

Looking at “puppet-puppet” and “puppet-foreman_proxy” - i can’t seem to find a way to configure these to coexist.

My “desired” configuration would be puppet-puppet manages my wildcarded autosign.conf entries, and $foreman_proxy::puppetca_provider is set to “false” or “undef” in order to disable both hostname_whitelisting, as well as fqdn_whitelisting. But it doesn’t look like the option exists to configure it this way yet…

Is there a better way (currently) to configure this? Allow hostname_whitelisting to exclusively manage it while the puppet-puppet module doesn’t manage the file at all?

2

Exactly this.

A static autosign is insecure because anyone who can connect to your Puppet CA can request a certificate and it’ll be signed.

Our puppetca_hostname_whitelisting solution adds it to the whitelist when relevant and removes after provisioning. This reduces the security impact to a timing attack where you need to know which host is being provisioned and request a certificate before it does.

There’s also puppetca_token_whitelisting which writes a cryptograhically signed token (JWT) during provisioning and the Puppetserver checks this token for validity. Docs for this are sparse and it’s not the default, but it’s the most secure way.

3

@ekohl

Thanks - this does make sense as a “better” way to do it.

As for actually accomplishing this - looking at the code: https://github.com/theforeman/puppet-puppet/blob/master/manifests/server/config.pp#L185-L204
https://github.com/theforeman/puppet-puppet/blob/master/manifests/server/config.pp#L71-L77

I’m not quite following.

I “think” i want to set:

$autosign = true,
$autosign_entries to the default ::params value of

This would end up “skipping” the file resource definition on line 196, and ensuring that the puppet.conf is configured with autosign = true (Line: 72)

Is this the correct way of enabling the behavior you describe? Apologies if this is simple and I’m just dense. I’m trying to follow the logic as best I can :frowning:

4

Correct. Setting autosign to true with an undef autosign_content and undef autosign_source will give you what you want.

The resource will be defined to ensure correct file permissions (foreman-proxy needs to write to it) but doesn’t manage the content (undef).