Hi Pete,
On Wed, 2011-09-14 at 12:08 -0600, Pete Zaitcev wrote:
In its present form iwhd has no access controls whatsoever, and it
concerns me. The memcached is like that too, and it is deployed successfully
on many high-traffic, high-profile sites. However, iwhd implies remote
access, which makes the current set-up more hazardous. I would like to
consider options from an attack by rooted systems on the internal
networks, and less privileged insiders.
A short while ago, there was some effort to underpin the whole cloud
with IPA. From that time, a patch exists for iwhd, which implements
Kerberos authentication. There is no authorization in it, however:
anyone who is able to authenticate with Kerberos is considered
authorized. I'm wondering if adding this to mainline iwhd would
help anything. Do Conductor and Factory have an HTTP-Negotiate
client support?
Failing that, I'd like to know if anyone has any suggestions or
requests. For example, would adding an HTTP-Basic (over SSL or not)
help anything?
One option would be to essentially make iwhd an internal component of
Aeolus, hidden behind conductor.
So:
1) Conductor would have a REST API for building and managing images,
basically identical to the functionality of the aeolus-image CLI
2) aeolus-image would talk to the Conductor REST API
3) Conductor would enforce any permissions appropriate for images and
image building
4) iwhd and Image Factory would be configured to only accept
connections from Conductor - e.g. using two-legged OAuth like
Katello does with Candlepin and Pulp
IMHO, that would be the best option for the short term.
Cheers,
Mark.