Ovirt devel - Jan 2009 - Ovirt Node Authorization and Security

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

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

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?
Yes, it sounds about right.  I'm also not sure about the
"Moderate" case;
besides the multiple admin problem, there is also the technical problem that we
currently don't have a "waiting pattern" mode for the ovirt node,
which we would
need to implement to get it to work.  But the idea is sane, and "Open"
and
"Highest" sound about how I thought about it.

-- 
Chris Lalancette

> From: ovirt-devel-bounces at redhat.com [mailto:ovirt-devel-
> bounces at redhat.com] On Behalf Of Ian Main
...
> 
> 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.
[IH] why not use TPM? Maybe not to store the keytab, but to store a
private key or a certificate which will allow authentication and
encryption only to this machine?
> 
> 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.).
[IH] if you don't persist the keytab (or at least persist some private key
in TPM to encrypt to), then what prevents badnode1 from spoofing goodnode2
and get its keytab from the admin server?
> 
> 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
> 
> 
> _______________________________________________
> Ovirt-devel mailing list
> Ovirt-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/ovirt-devel