How to run puppet-master on 443

We have to deal with running hosts within our clients’ networks where our only access out is through HTTP proxies. Problem is, many proxies by default don’t allow access to non-standard ports (anything except 80 and 443). As such accessing the puppet-master on 8140 fails. This is a pain, but we have no control over it.

How can I run Foreman’s puppet-master on 443?

I’m running Foreman within AWS so tried adding a load balancer on 443 that targeted the puppet-master on 8140. But I think this fails because the puppet-agents somehow check the cert of the master, not the load balancer.

I have thought about running Foreman only on port 80, and then putting a load balancer in front of that on a different address with its own SSL certificate but I see the foreman Apache setup is designed to handle client certificates. So that would break. But I’m not sure if that’s a problem for my situation. If Foreman’s not running on 443 then I could run the puppet-master on 443 (or just pipe 443 to 8140).

I could also run another puppet-master on a separate host, and run that one on 443. But I’m not sure how then to set hosts that Foreman creates to use the alternate puppet-master and the 443 port instead of 8140.

I just don’t know enough about the restrictions / requirements for Foreman and Puppet with SSL to be able to know what is a viable option.

Any suggestions or pointers appreciated.

I can see this has been asked a few years ago: Configure puppet-master on 443 rather then 8140 But there was no response.

Thanks in advance.

The easiest way is to deploy a foreman proxy + puppet master on a separate host. That frees up port 443. Then register that foreman-proxy to Foreman. It should detect the Puppet feature and allow selection. I’d also advise to remove the Puppet master from the Foreman server.

To test with this a while back I also went a step further by running Foreman, Foreman Proxy and Puppetserver on 3 separate servers. At this point I wouldn’t recommend it, but splitting of the proxy + Puppetserver is a good idea. See the PR for some inspiration:

Thanks @ekohl. I was thinking the best result would be a Foreman and Puppet running on separate servers but couldn’t find anything describing this scenario. What I had read suggested leaving the Puppet CA on the Foreman sever. Would you suggest moving the CA as well onto the Puppet server?

Thanks to your PR above @ekohl and a few other web resources I got it going. I created a gist of what I ran on each server to have Foreman on one, and a smart-proxy + Puppet on the other linked up.

One thing to note. I assume because the puppet CA isn’t on the Foreman server the foreman-installer can’t create the certificates used in the apache2 config. As such apache2 starts on port 80 but not on 443. However, foreman-installer reports Success! and Foreman is running at https://... but in fact it is not. Maybe the installer should check it can connect to the foreman web interface?

To get the oauth-consumer value you can also use foreman-rake config -- -k oauth_consumer_key and foreman-rake config -- -k oauth_consumer_secret.

I would actually advise a slightly different strategy for the setup:

  • Install Puppet + Foreman Proxy first but don’t register the proxy by adding --foreman-proxy-register-in-foreman false to the foreman-installer command
  • Install Foreman as you do now
  • Register the Foreman Proxy running foreman-installer --foreman-proxy-register-in-foreman true --foreman-proxy-oauth-consumer-key OAUTH_KEY --foreman-proxy-oauth-consumer-secret OAUTH_SECRET on that host.

Then I think you can drop the whole SSL setup code you have.

1 Like

Ahhh… can foreman-installer create and pull the certificates it needs for Apache from the remote proxy? That is awesome.

PuppetCA is a networked CA server. Adding the Foreman server to the autosign entires is not great and is not recommended for production. Probably good to add --reset-puppet-autosign-entries after registration.

FYI I’ve updated the gist with your recommendations:

The puppet symlinks shouldn’t be needed. puppet-agent installs a file in /etc/profile.d/ that adds it to $PATH. Your shell doesn’t source it after installing but on a fresh install it should.

@ekohl You are correct about the puppet symlinks. I just needed to run sudo with -i to get /etc/profile run and therefore puppet in the PATH.