Open Stack

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 at redhat.com> 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 at seetheprogress.net> 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 :|