[Ovirt-devel] ovirt and freeipa

[Jeremy Katz]

On Thursday, April 09 2009, Hugh O. Brock said:
> On Thu, Apr 09, 2009 at 12:31:25PM -0700, Ian Main wrote:
> > On Thu, 9 Apr 2009 14:11:21 -0500 (CDT)
> > Mike McGrath <mmcgrath at redhat.com> wrote:
> > > So if we have an organization that, for any reason, cannot run freeipa.
> > > They cannot use ovirt.  Freeipa is a false requirement for cloud and
> > > virtualization.
> > > 
> > > The web frontend already uses basic auth, by doing this it makes it easy
> > > to swap auth out with many of the apache mod_auth modules allowing people
> > > to pick whatever auth mechanism they want.
> > > 
> > > Use case:
> > > 
> > > 1) Admin uses mod_auth_postgres
> > > 2) User exists in postgres logs in to ovirtwui
> > > 3) ovirt creates the user if it doesn't exist
> > > 4) admin can then create permissions and things for the user
> > > 
> > > How hard would it to be the above?
> 
> I'd be perfectly happy to offer this as an option, or some other form
> of pluggable authentication. We wanted to avoid writing our own user
> management system for oVirt and using IPA for it seems like an obvious
> choice, but it does not have to be the only choice.

The question that comes to my mind at least is do we expect oVirt to be
deployed within a vacuum (ie, it is a system unto itself) or within a
larger ecosystem.  If the latter, then pluggable is probably the only
way to go.  And at that point, having a super-simple "dummy" type system
for when you're not plugging into a larger org's existing auth mechanism
may be simpler than having oVirt depend on a full-blown IPA setup even
if it is something we have to write ourselves.  It could be nothing more
than a combination of a sqlite db on disk + hashed passwords.  

If, instead, we think that oVirt deployments should be largely run unto
themselves, then building in IPA and using IPA for everything makes
sense.  But at that point, we should really be sure we're using it and
not try to give outs for people to plug in different things


> > The other issue is that the qpid infrastructure is currently set up
> > to require kerberos authentication.  However, it's kind of silly in
> > a way because the default roll out has it grabbing the ticket from
> > the web server specified in the DNS SRV records, which means that no
> > authentication of nodes really takes place.  The right way to securely
> > connect nodes is to copy the ticket to some persistent storage on the
> > node before deployment.
> > 
> > The thing this protects against is malicious nodes.. note that a VM
> > could also register as a node so you have to trust your VMs too..
> > this is actually a problem with the current default config.  Note
> > that you don't need a node image booted, you just need the ovirt
> > scripts to register with the ovirt server etc.  The danger of a rogue
> > node is that it gives that node access to whatever VMs happen to get
> > created on it (take snapshot, scp it to home computer or such - image
> > stealing).
> > 
> > I think it would be a good idea to enable the qpid infrastructure to
> > work without kerberos for demoing/testing/evaluating.
> > 
> > If we could have a mode where we get rid of the freeipa and dns
> > requirements, it would definitely make it much easier to deploy for
> > evaluation etc.  It would be good for developers to get up and running
> > as well which may also be advantageous.
> 
> As I've said elsewhere, I think it's going to be difficult for us to
> avoid having a coherent authentication and encryption system between
> the server and the nodes, and for that we have two choices: kerberos
> and PKI. I think it's a really bad idea to offer a "development" mode
> where one of those systems are not enabled, because they will never
> get any testing otherwise. Ultimately that means you need working DNS
> on the admin network, but I don't see why this has to be a showstopper
> requirement.

There are plenty of ways that don't involve working DNS -- IP-based, SSH
keys, func doesn't iirc.  Even using SSL certs doesn't have any
strong requirements around DNS for the most part.  The developer mode
certainly needs to do auth and encryption, but we may be making both of
those harder than they need to be.

Kerberos has a lot of really nice advantages for a certain set of
applications.  If you get outside of that, it really starts to be
hammering a square peg into a (smaller) round hole.
 
> The questions around the boot process are a little bit of a red
> herring. If you are working in an infrastructure where you don't trust
> your nodes, then you use the mechanisms already built into the node to
> store a key locally. If you do trust your environment to not have
> malicious people spoofing mac addresses (like several clients I've
> visited), then you can use the mac address.

To be perfectly honest, the local storage story with the node is very
weak and to Mike's earlier points, is a whole other new set of things to
learn.  Even if you do a node "install", only special things are
preserved.  And then on top of that, the provisioning of the node is
unlike anything else you're doing.  So if we really care about the "node
running off of a disk" case, then getting to where it's a more normal
type of provisioning/installation is going to help a lot in getting
admins more comfortable.

Jeremy