Foreman 1.24 - way to determine the variable puppetmaster and puppet_ca

Hello everybody,
after updating foreman from 1.23 to 1.24.X, foreman changed the way to determine the variable puppetmaster and puppet_ca (https://github.com/theforeman/foreman/commit/c2317d4430325be04df9ddfe65f47223b7733b8b).
With puppet 5/6 the way to manage the puppet certificates changed to http. With puppet 6 you also need the certificate extension “pp_cli_auth” to administrate the puppetca (with foreman smart proxy).
For security reason, certificates with this extension should only be created for a few server - in my opinion only for the puppetca itself. As a consequence the foreman smart proxy for the puppetca should only be installed on the puppetca servers.

In my opinion, the combination of the new way to determine the variable puppetmaster and puppet_ca and puppet 6 significantly reduces the possibility and flexibility how you can set up your foreman/puppet infrastructure.

Example / wow we designed our foreman / puppet infrastructure
For our network infrastructure segments we use a central foreman / puppet cluster. This cluster is based on several dedicated server for foreman, the puppetmaster and puppetca. In front of these nodes there is a loadbalancer, which distributed the https requests to the backend nodes. In every network segment there are additional proxy server, which forward and centralize the traffic via a virtual ip to the loadbalancer. Furthermore we installed the foreman smart proxy on these proxy server, with the features puppet, puppetca, template, … activated.
Until Foreman 1.23 this gave us the opportunity to dynamical determine the address of the puppet master and puppet ca for the puppet client through the variable puppetmaster and puppet_ca from foreman. With foreman 1.24 this isn’t possible any more.

Is it possible to add a feature switch in foreman to support both variants of the determination of the variables puppetmaster and puppet_ca? Or do you have any suggestions for the layout of such a environment?

If you need further data, please let me know.

kind regards

Anybody an idea?

When using Puppet 6, the smart proxy fully talks over http(s) to the Puppetserver. Since 1.22 these URLs are exposed to Foreman. Since 1.24 these URLs are used in Foreman. This is probably what you are seeing.

Is there a reason you’re not pointing the Smart Proxy to your load balancer to the same address as their clients should talk to? That is the intended design.

Hi @ekohl,
if we use an http proxy, it must have a certificate from the puppetca with the ca extensions. Clients that connect to this proxy address now have full access to the puppetca. An alternative would be a tcp proxy, but this restricts the choice considerably (haproxy,…?)

Furthermore, we need significantly more servers with a certificate that has the puppetca extensions - in each lan segment at least two.
In my opinion, this increases the attack surface on the puppetca.

What are the recommendations for the architecture of the infrastructure in such complex environments?

So as I understand it you have:

Previously the foreman-proxy on every proxy-segment-x connected to foreman.example.com bypassing all authentication while the clients in that segment connected to proxy-segment-x.example.com.

Is there a reason that Foreman Proxy can’t connect to its own FQDN and use authentication? In Puppetserver you can authorize hostnames. The benefit would be that you properly use the Foreman. Overriding via parameters was AFAIK never a feature that was intended. Another is that you don’t need to expose an unsecured HTTP endpoint in your infrastructure. An example how to do so:

If I misunderstood anything, please let me know.