[Ovirt-devel] ovirt and freeipa

[Hugh O. Brock]

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 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.

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.

As far as I'm concerned, what we need to do is keep troubleshooting
the installer and make it as painless as possible in a two-network
case, and add some additional authentication methods for the UI side.

Thanks,
--Hugh