[Ovirt-devel] Ovirt Node Authorization and Security

Ian Main imain at redhat.com
Thu Jan 15 01:27:04 UTC 2009


So while setting up qpid to work with gssapi/kerberos, I've been doing
a bit of thinking about how our security model is going to work.  I
think some of you may have this figured out already but I thought I'd
post and just make sure we're all on the same page.

As it stands now, ovirt nodes are set up to download the keytab from the
server (in ovirt-awake script).  This is then used by libvirt to
authenticate the server.  Once switched to qpidd it'll be much the same
except we'll be grabbing a keytab for the qpidd service on the ovirt
appliance.

This is fine for a trusted network (where really, we don't even need
encryption/host verification), but on an untrusted network it's quite
possible for a malicious host to go through the same initialization
process and then become one of the nodes and then have access to any VMs
that are started/migrated to it.

For the unprotected network case then, we want to control the
distribution of the keytabs.  We could have two levels of security
based on how anal one wants to be.  This would give us security
settings that might look something like:

Highest: For each new machine brought into ovirt pool one would be
required to have a keytab generated in advance and either copied into
persistent storage on the machine or put on a USB stick etc.

Moderate: Each time a node registers with the wui, it is placed in an
authorization queue and is required to be authorized by an
administrator before a keytab is generated for the node and made
available for download. Any pertinent information about the node will be
displayed in the list (MAC, maybe hardware ID etc.).

Open: As it is now, where a keytab is just downloaded automatically.

I have a bit of a reservation around 'Moderate' as there may be
multiple admins and someone might just assume a machine is fine
and authorize it just because it's there.  I guess that'd be up to
the policy and SOP of the organization involved.

I'm not sure what our requirements are for the release but as it stands
currently we only implement the 'open' version.

This sound reasonable to everyone?

	Ian





More information about the ovirt-devel mailing list