iwhd security

Mark McLoughlin markmc at redhat.com
Wed Sep 14 18:22:00 UTC 2011


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.



More information about the iwhd-devel mailing list