Manage content hosts in another network

Support
,
1

Problem:
I am looking for advice on how I may extend Foreman/Katello.
Currently, I am using Foreman/Katello in one network, and for the time being, I only manage Content Hosts, i.e. manage software packets, run updates, schedule reboots.
(not using configuration management, host provisioning etc.)

Now I would like to manage Content Hosts in another network in the same manner.
Foreman doesn’t have direct network connection to these hosts, so either I would have to build a Smart Proxy, or pull from remote hosts (e.g. MQTT) rather than push (using SSH), or use a SSH bastion host for Foreman.
As the total host count is rather small, it doesn’t pay off to build a large solution. It would be better not to build a Smart Proxy at all, but if it’s impossible without Smart Proxy, at least manage Content Hosts without having a copy of all the contents on the Smart Proxy. (i.e. Products, Repositories, Content Views, etc)

How could this be built, and is there documentation about it?

Expected outcome:
N/A

Foreman and Proxy versions:
3.5.1

Foreman and Proxy plugin versions:
foreman-tasks 7.1.1.
foreman-remote-execution 8.2.0.
katello 4.7.3

Distribution and version:
Rocky Linux 8

2

Remote execution’s pull-mqtt mode, while it’s true it doesn’t require an SSH connection, still requires an HTTPS connection between host and smart proxy.

I think a Smart Proxy with Content will solve your issue. It would just need to have a network connection both to the main Foreman server and to your hosts.

You don’t have to sync all your content between the main Foreman server and smart proxy. (In fact, this is not recommended.) You can instead choose to sync only a single lifecycle environment: Installing an External Smart Proxy Server 3.5

Here’s the documentation on setting up a smart proxy with pull-mqtt: Installing an External Smart Proxy Server 3.5

Configuring hosts to use the pull client: Managing Hosts

1 Like
3

Sending data from many hosts to the Smart Proxy is much simpler - these are outbound connections trying to reach one IP.
As opposed to the other way around, which is inbound connections, where one IP is trying to reach many, behind a firewall.

Are you saying that HTTPS is required in addition to MQTT?

Do you know if MQTT can be routed through a reverse-proxy or WAF, or does it have directly connect to the Smart Proxy (in terms of layer 7)?

4

Yes. Hosts subscribe to job notifications with MQTT, but they download job details and report status with HTTPS. See the prerequisites list here.

I’ll leave this question for @aruzicka .

1 Like
5

Both mqtt and https connections originate from the hosts reaching the proxy. Once the connection is established, data can flow both ways. So as long as the hosts can contact foreman/smart proxy directly, you’re good to go with pull.

Eh, if you had a layer 7 proxy that would understand mqtt as a protocol then maybe yes? But as long as the hosts can reach foreman (which I assume they can, otherwise they wouldn’t be able to get content) you shouldn’t need this

1 Like
6

Thank you @aruzicka
Just to explain, where this idea is coming from:
Using a reverse-proxy / WAF in this context could make sense:

  • If a company wants to inspect all traffic, and filter malicious traffic
  • if a company wants better auditability about all incoming traffic
  • if the architecture is made in a way that there is only one “front-door” for all incoming traffic
7

Thank you for the context. I was looking at it more from the “would it be strictly necessary to use such a thing” perspective

1 Like