[Ovirt-devel] Ovirt Node Authorization and Security

[Perry Myers]

Ian Main wrote:
> 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?

Sounds reasonable to me. :)

Perry