openstack team mailing list archive

[Eddie Garcia <eddie.garcia@xxxxxxxxxxx>]

Michael,

IMO there are several encryption and key management things to consider so it really depends
on your needs. If you are looking to allow VM owners to meet data at rest compliance or policies
then allow them to manage their own encryption keys and rotation policies then a solution
like Justin described encrypting "inside the disk" image does work and the performance impact
is low. You can do some experimentation with ecryptfs and layer that on your existing storage. You
can checkout the Ubuntu encrypted home directories as a reference.

Now if you are a service provider and would like to disassociate yourself from any subpoenable
content that may be stored on your servers, then you may want to do encrypt entire storage
by default, then store your encryption keys in keystone maybe.

For compute, as Matt mentioned protecting your in-memory data from root or from the hypervisor is not that easy
you can make it harder, but there isn't a really good solution today. Longer term trust models that go
from metal to hypervisor to tenants using technologies TPM, remote attestation will provide the 
extra security layers.


-Eddie

On Apr 26, 2012, at 5:34 PM, Justin Santa Barbara wrote:

> I think one of us is misunderstanding the model.  My understanding is that we produce software that we trust, and then prove to the caller that we're running that software.  All optimizations remain possible.
> 
> Check out section 6.1 of the paper!
> 
> 
> On Thu, Apr 26, 2012 at 3:24 PM, Matt Joyce <matt@xxxxxxxxxxxxxxx> wrote:
> Functionally if the scheduler doesn't know what it's passing to the
> CPU or into paging memory a lot of optimization possibilities go out
> the window.  If it does know one can infer a great deal about your
> datasets protected or not.
> 
> -Matt
> 
> On Thu, Apr 26, 2012 at 3:08 PM, Justin Santa Barbara
> <justin@xxxxxxxxxxxx> wrote:
> > I think that Intel's trusted cloud work is trying to solve that exact
> > compute host problem.  It may already have the framework to do so even if
> > the software hasn't caught up (i.e. if we still have some work to do!)
> >
> > It relies on a TPM chip, all code is measured before being run, and then
> > there's a protocol to prove that a system is running that code (remote
> > attestation).  If you change the software stack by introducing a sniffer,
> > you change the hash.  So we'd need a stack with no root-access / back-doors.
> >  Once a back-door becomes known, the hash should no longer be trusted.
> >
> > I'm by no means an expert (I'm still learning about it), but I believe it is
> > possible, having read this
> > paper: http://www.research.ibm.com/trl/projects/watc/FredericStumpfPaper.pdf
> >
> > I'm sure there are still exploits (hardware RAM taps?), and we rely on a
> > total code audit, but we can raise the bar a long way.
> >
> > Anyone from Intel / familiar with Intel's trusted cloud work want to explain
> > better than I can?
> >
> > Justin
> >
> >
> >
> >
> > On Thu, Apr 26, 2012 at 1:44 PM, Matt Joyce <matt@xxxxxxxxxxxxxxx> wrote:
> >>
> >> As far as storage is concerned, certainly a cloud storage environment
> >> could be leveraged to store pre-encrypted data in such a way that
> >> would make it difficult bordering on impossible to seize or access
> >> without the consent of the owner.
> >>
> >> As far as compute hosts are concerned, it is a whole different matter.
> >>
> >> For the foreseeable future ( barring the invention of new widely
> >> distributed in CPU technology ) .  Anyone with ring 0 execution access
> >> on a system ( ie root / sudo ) will be able to pull data from a
> >> running instance pretty much no matter what you do.
> >>
> >> You can certainly raise the bar on difficulty there, but the
> >> fundamental path of sniffing schedulers / paging memory / etc will be
> >> there for a fairly long time.  Even trusted computing wouldn't be
> >> applicable to protecting a vm's scheduler from the hypervisors owner.
> >>
> >> So, I think functionally it should be assumed that a provider will be
> >> able to access anything that you access on a hosted VM.  As far as a
> >> trust relationship goes in elastic computing, there must be an
> >> implicit trust of the cloud provider.  And as with any trust
> >> relationship there is always going to be an element of risk.
> >>
> >> -Matt
> >>
> >> On Thu, Apr 26, 2012 at 9:53 AM, Daniel P. Berrange <berrange@xxxxxxxxxx>
> >> wrote:
> >> > On Thu, Apr 26, 2012 at 09:05:41AM -0700, Matt Joyce wrote:
> >> >> From a security stand point I am curious what you see the benefit as?
> >> >
> >> > Consider that you might have separate people in your data center
> >> > managing the virtualization hosts, vs the storage hosts vs the
> >> > network. As it standards today any of those groups of people can
> >> > compromise data stored in a VM disk image (assuming a network based
> >> > filesystem).
> >> >
> >> > First you encrypt the disk image, so that a person with access
> >> > to the storage hosts, or network sniffing can't read any data. Then
> >> > you have a central key server that only gives out the decryption key
> >> > to Nova compute nodes when they have been explicitly authorized to
> >> > run an instance of that VM.
> >> >
> >> > So now people with access to the storage hosts cannot compromise
> >> > any data. People with access to the virtualization hosts can only
> >> > compromise data if the host has been authorized to use that disk
> >> > image
> >> >
> >> > You would need to compromise the precise host the VM disk is being
> >> > used on, or compromise the key server or the management service
> >> > that schedules VMs (thus authorizing key usage on a node).
> >> >
> >> > NB this is better than relying on the guest OS to do encryption,
> >> > since you can do stricter decryption key management from the
> >> > host side.
> >> >
> >> >> On Thu, Apr 26, 2012 at 8:53 AM, Michael Grosser
> >> >> <dev@xxxxxxxxxxxxxxxxxx> wrote:
> >> >> > Hey,
> >> >> >
> >> >> > I'm following the openstack development for some time now and I was
> >> >> > wondering if there was a solution to spin up encrypted virtual
> >> >> > machines by
> >> >> > default and if it would be a huge performance blow.
> >> >> >
> >> >> > Any ideas?
> >> >
> >> > I would like to extend the libvirt driver in Nova to make use of the
> >> > qcow2
> >> > encryption capabilities between libvirt & QEMU which I describe here:
> >> >
> >> >
> >> >  http://berrange.com/posts/2009/12/02/using-qcow2-disk-encryption-with-libvirt-in-fedora-12/
> >> >
> >> > Regards,
> >> > Daniel
> >> > --
> >> > |: http://berrange.com      -o-
> >> >  http://www.flickr.com/photos/dberrange/ :|
> >> > |: http://libvirt.org              -o-
> >> > http://virt-manager.org :|
> >> > |: http://autobuild.org       -o-
> >> > http://search.cpan.org/~danberr/ :|
> >> > |: http://entangle-photo.org       -o-
> >> > http://live.gnome.org/gtk-vnc :|
> >>
> >> _______________________________________________
> >> Mailing list: https://launchpad.net/~openstack
> >> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> >> Unsubscribe : https://launchpad.net/~openstack
> >> More help   : https://help.launchpad.net/ListHelp
> >
> >
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp