[Spacewalk-list] Using internal spacewalk to manage DMZ hosts?

[Ben Roberts]

Hi all,

I'm looking to extend an existing internal spacewalk to also allow
management of DMZ hosts without having to setup a completely parallel
infrastructure. I'd like some advice on how best to lock it down to
prevent a compromise of any host in the DMZ (either a client, or the
proxy host itself) being used as a platform to attack the internal
spacewalk server.

The approach I am considering is running a chain of two Proxy servers,
one on inside the DMZ and one internally, with firewall holes open
between the two Proxy servers only. I think this would ensure the
external proxy doesn't have direct access to communicate with the real
master, and any lockdown done on the internal proxy doesn't affect
functionality for internal clients. I see that I can disable proxying
of the webui, content push (rhn), applet, cobbler, config management
and applet endpoints by tweaking the spacewalk-proxy-wsgi apache
config file to expose the bare minimum services.

However, I'm concerned about the security of the XMLRPC itself. Is
there any way to permit only "system registration" and other "read
only" API functions necessary for client management (e.g. repo
metadata download)?
If I understand correctly, leaving the api as-is means the only
protection that stands in the way of a password brute force against
the admin account via the api interface is a 2s delay on failed
logins. Is there any built-in, or suitably easy addon method to
whitelist IP addresses for auth.* calls?

If I'm on completely the wrong track, how are other people on this
list managing DMZ hosts using spacewalk?

Thanks all,
Ben Roberts