We’ve been evaluating Foreman and would like to confirm our understanding of some of its limitations with regard to managing multiple data centers over the (untrusted) Internet.
Smart proxies don’t have a notion of a unique data center name, which could be added during discovery to help differentiate hosts that are discovered in different data centers but which have the same private networks.
Hosts need to communicate to the master for the auto-installation template, but this channel is not secure, which means that the root password is sent in the clear.
Many installers don’t support fetching the unattended installer config over HTTPS. Smart Proxies are not yet able to proxy that request, upgrading it from HTTP inside the private network to HTTPS over the WAN to the master.
We might be inclined to help implement some of the features needed to be able to have Master <–> Proxy communication over an untrusted network, if the work is well-scoped and there is some community support for it. Does the above list seem comprehensive? Or is there other communication to the master that is not well-secured?
No but they do have a name and combined with auto-discovery rules, you could assign a Location or another attribute to a host automatically.
Smart Proxy does forward requests to the Foreman server, (IIRC port 8443 on the proxy will get you 443 on the Foreman Server) What OS are you provisioning? for example, Kickstart has the encrypted string in the kickstart file, also you can set your kickstart URL to https.
Some mod_proxy Apache config could do the trick. If you are using the installer, which I hope you are, you may need to modify the Puppet modules, if you do send a PR
Awesome! Thanks for correcting my misunderstandings! We’ll keep pushing ahead and report back if we run into any issues with this setup. Our plan is to block all inbound master communication except for HTTPS from the proxies.
Okay, another question: For the discovery GRUB config, there’s a value indicating where the host should post back its discovered facts. This results in direct communication from the hosts to the master, which we’d like to avoid. It means that we need to open up extra ACLs for the gateway IPs of each data center. (In addition to the IPs for the smart proxies.)
It appears that there’s only one GRUB config, so there’s no way to set the address to different smart proxies, depending on which data center the host is in. Is there a variable that expands to “the private IP of whichever proxy is associated with this data center”?
@lzap can give a better answer, no doubt, but in general the answer is always yes. Foreman’s templating engine is pretty powerful, so even if there isn’t a specific macro to use to get that IP, you could construct something in ERB to get at other attributes.
That said, I’m not sure we actually store the IP in question (a proxy is a name, a URL, and a set of features), so the two routes I can think of are (a) add a parameter at some hierarchy level, maybe Subnet or Domain, that holds the IP you need, or (b) if the proxy is in Foreman too, that could be queried for it’s IP, eg
<% proxy = @host.dns_proxy.name #assuming name is actually the hostname... %>
ip = <%= Host.find_by_name(proxy).primary_interface.ip %>
That’s untested code, of course, but it gives you an idea of what’s possible. Sadly much of this flexibility is gated behind our Safemode option, which restricts what you can do in a template (for good reason, this power can be used irresponsibly) so you may find the parameter approach better.
Other, more complex solutions exist too, but this post is long enough already
Discovery kernel command line lives in PXELinux/Grub/Grub2 Global Template. This template is rendered without @host in context so this will be nil pointer exception. The problem is we don’t have @smart_proxy in the context as well, it’s pretty much empty context, therefore the only reasonable thing we do is we set the discovery URL to foreman_url which is known helper.
We are tracking a feature ticket to automatically set the URL to capsule hostname, can’t find it tho. But the good news is - this can be configured. All you need to do is edit the default/grub.cfg after Global template is deplyed and change this:
And it will work assuming that you have discovery smart proxy plugin installed. It’s a trivial plugin that provides HTTP proxy for client-node and node-client communication.
Last time I attempted to implement the feature there were some limitations of our spaghetti templating code, now it’s being refactored so I might take another look after we merge this awesome refactoring actually!
