Re: [openstack-dev] [nova] Encrypted Ephemeral Storage

[Coffman, Joel M.]

Based on the comments to the RBD encryption change [1], it looks like there 
will be a new direction for ephemeral disk encryption (embedding it in QEMU 
directly). I assume LVM will work the same way when the time comes. Will there 
be a migration path for the existing ephemeral disk encryption support for LVM 
to the new model?

[1] https://review.openstack.org/#/c/239798/

Yes, as I understand it, the long-term goal is to provide encryption support 
directly in QEMU and have a unified interface for LVM, RBD, and file-based 
backends. I do not yet know what the potential migration path will look like.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Encrypted Ephemeral Storage

[Coffman, Joel M.]

> Upon reading the source, I don't see "cryptsetup luksFormat" being called 
> anywhere (nova/libvirt/storage/*).
Check out 
imagebackend.py:Lvm.create_image
 and 
dmcrypt.py:create_volume.

> How is this feature envisioned to work?
The LVM volume with the '-dmcrypt' suffix is the unencrypted device that is 
passed to the VM. From a DevStack machine with an encrypted instance:

$ sudo cryptsetup status 
/dev/mapper/065859b2-50d6-46d6-927a-2dfd07db3306_disk-dmcrypt

/dev/mapper/065859b2-50d6-46d6-927a-2dfd07db3306_disk-dmcrypt is active and is 
in use.

  type:PLAIN

  cipher:  aes-xts-plain64

  keysize: 256 bits

  device:  
/dev/mapper/stack--volumes--default-065859b2--50d6--46d6--927a--2dfd07db3306_disk

  offset:  0 sectors

  size:2097152 sectors

  mode:read/write

$ sudo fuser -vam /dev/mapper/065859b2-50d6-46d6-927a-2dfd07db3306_disk-dmcrypt

 USERPID ACCESS COMMAND

/dev/dm-1:   libvirt-qemu   8429 F qemu-system-x86

While information in the '*-dmcrypt' device is visible to a root user on the 
compute host, the underlying device (stack--volumes--default-* in the example 
above) is encrypted, and everything written to the underlying disk is also 
encrypted. Try searching for the text in the underlying device – you shouldn't 
be able to find it.

Joel


From: Chris Buccella 
>
Reply-To: 
"openstack-dev@lists.openstack.org" 
>
Date: Monday, April 11, 2016 at 1:06 PM
To: 
"openstack-dev@lists.openstack.org" 
>
Subject: [openstack-dev] [nova] Encrypted Ephemeral Storage

I've been looking into using encrypted ephemeral storage with LVM. With the 
[ephemeral_storage_encryption] and [keymgr] sections to nova.conf, I get an LVM 
volume with "-dmcrypt" is appended to the volume name, but otherwise see no 
difference; I can still grep for text inside the volume.

Upon reading the source, I don't see "cryptsetup luksFormat" being called 
anywhere (nova/libvirt/storage/*).

I was expecting a new encrypted LVM volume when a new instance was created. Are 
my expectations misplaced? How is this feature envisioned to work?


Thanks,

-Chris
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder][nova]Move encryptors to os-brick

[Coffman, Joel M.]

On 12/2/15, 4:01 PM, "Ben Swartzlander" <b...@swartzlander.org> wrote:

>On 11/30/2015 09:04 AM, Coffman, Joel M. wrote:
>>
>>
>> On 11/25/15, 11:33 AM, "Ben Swartzlander" <b...@swartzlander.org
>> <mailto:b...@swartzlander.org>> wrote:
>>
>> On 11/24/2015 03:27 PM, Nathan Reller wrote:
>>
>> the cinder admin and the nova admin are ALWAYS the same
>>people
>>
>>
>> There is interest in hybrid clouds where the Nova and Cinder
>> services
>> are managed by different providers. The customer would place
>>higher
>> trust in Nova because you must trust the compute service, and
>>the
>> customer would place less trust in Cinder. One way to achieve
>>this
>> would be to have all encryption done by Nova. Cinder would
>> simply see
>> encrypted data and provide a good cheap storage solution for
>>data.
>>
>> Consider a company with sensitive data. They can run the compute
>> nodes
>> themselves and offload Cinder service to some third-party
>>service.
>> This way they are the only ones who can manage the machines
>>that see
>> the plaintext.
>>
>>
>> If you have that level of paranoia, I suggest running LUKS inside
>>the
>> guest VM and not relying on OpenStack to handle your encryption.
>>Then
>> you don't have to worry about whether nova is sharing your keys with
>> cinder because even nova won't have them.
>>
>> That approach isn't actually more secure — anyone with root access to
>> the compute host can dump the VM's memory to extract the encryption
>>keys.
>
>I agree, however in the above case there was implied trust in the
>compute infrastructure -- at least more so than in the storage
>infrastructure. If you don't trust your hypervisor admin to not read
>your VM memory and steal encryption keys, then relying on your
>hypervisor admin (or nova) to perform the encryption is kind of silly.
>In every case, the hypervisor admin can see the plaintext and the keys.
>
>The suggestion was a way to achieve the goal of doing encryption WITHOUT
>trusting the storage admin and WITHOUT CHANGING ANY CODE. I assert that
>any attempt to implement encryption at the nova level and not sharing
>keys with cinder will break the existing model. There are 2 solutions I
>can see:
>1) don't break it (see above)
>2) you break it, you fix it (nova takes over responsibility for all the
>operations cinder currently performs that involve plaintext).
So perhaps it would be fair to describe the existing encryption support as
comparable to the proposal to use LUKS inside the guest VM?

>> Trying to design a system where we expect nova to do data
>>encryption but
>> not cinder will not work in the long run. The eventual result will
>>be
>> that nova will have to take on most of the functionality of cinder
>>and
>> we'll be back to the nova-volume days.
>>
>> Could you explain further what you mean by "nova will have to take on
>> most of the functionality of cinder"? In the current design, Nova is
>> still passing data blocks to Cinder for storage – they're just encrypted
>> instead of plaintext. That doesn't seem to subvert the functionality of
>> Cinder or reimplement it.
>
>I think Duncan covered it, but the data operations cinder currently
>performs, which require Cinder to touch plaintext data are:
>1) Create volume from glance image
>2) Create glance image from volume
>3) Backup volume
>4) Restore volume
>
>I'm not claiming that we can't redefine or alter the above operations to
>deal with encryption, but someone needs to propose how they should work
>differently or work at all when the volume isn't storing plaintext data.
The operations listed seem to have the same issues with encryption inside
a VM and the existing implementation.
1) Create volume from Glance image: Since Glance doesn't support
encryption (yet), this volume would be unencrypted and any discussion
about encryption is a moot point.
2) Create Glance image from volume: If the volume is encrypted (using
encryption inside the VM or the current implementation), then eventually
trying to use this image to boot a VM will fail *unless* there is a way to
provide the key when the image is spawned. If Glance eventually supports
the same encryption metadata as Cinder, then the current implementation
should "just work."
3) Backup / restore volume: Encryption inside the VM has the same issues
as the current implementation.

Of course, both techniques (

Re: [openstack-dev] [cinder][nova]Move encryptors to os-brick

[Coffman, Joel M.]

From: "duncan.tho...@gmail.com<mailto:duncan.tho...@gmail.com>" 
<duncan.tho...@gmail.com<mailto:duncan.tho...@gmail.com>>
Reply-To: 
"openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Monday, November 30, 2015 at 9:13 AM
To: 
"openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [cinder][nova]Move encryptors to os-brick

On 30 November 2015 at 16:04, Coffman, Joel M. 
<joel.coff...@jhuapl.edu<mailto:joel.coff...@jhuapl.edu>> wrote:
On 11/25/15, 11:33 AM, "Ben Swartzlander" 
<b...@swartzlander.org<mailto:b...@swartzlander.org>> wrote:

On 11/24/2015 03:27 PM, Nathan Reller wrote:
Trying to design a system where we expect nova to do data encryption but
not cinder will not work in the long run. The eventual result will be
that nova will have to take on most of the functionality of cinder and
we'll be back to the nova-volume days.
Could you explain further what you mean by "nova will have to take on most of 
the functionality of cinder"? In the current design, Nova is still passing data 
blocks to Cinder for storage – they're just encrypted instead of plaintext. 
That doesn't seem to subvert the functionality of Cinder or reimplement it.

The functionality of cinder is more than blindly storing blocks - in particular 
it has create-from/upload-to image, backup, and retype, all of which do some 
degree of manipulation of the data and/or volume encryption metadata.
From a security perspective, it is advantageous for users to be able to upload 
an encrypted image, copy that image to a volume, and boot from that volume 
without decrypting the image until it is booted.

We are suffering from somewhat incompatible requirements with encryption 
between those who want fully functional cinder and encryption on disk (the 
common case I think), and those who have enhanced security requirements.
The original design supports this distinction: there is a "control-location" 
parameter that indicates where encryption is to be performed (see 
http://docs.openstack.org/user-guide-admin/dashboard_manage_volumes.html).
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder][nova]Move encryptors to os-brick

[Coffman, Joel M.]

On 11/25/15, 11:33 AM, "Ben Swartzlander" 
> wrote:

On 11/24/2015 03:27 PM, Nathan Reller wrote:
the cinder admin and the nova admin are ALWAYS the same people

There is interest in hybrid clouds where the Nova and Cinder services
are managed by different providers. The customer would place higher
trust in Nova because you must trust the compute service, and the
customer would place less trust in Cinder. One way to achieve this
would be to have all encryption done by Nova. Cinder would simply see
encrypted data and provide a good cheap storage solution for data.

Consider a company with sensitive data. They can run the compute nodes
themselves and offload Cinder service to some third-party service.
This way they are the only ones who can manage the machines that see
the plaintext.

If you have that level of paranoia, I suggest running LUKS inside the
guest VM and not relying on OpenStack to handle your encryption. Then
you don't have to worry about whether nova is sharing your keys with
cinder because even nova won't have them.
That approach isn't actually more secure — anyone with root access to the 
compute host can dump the VM's memory to extract the encryption keys.

Trying to design a system where we expect nova to do data encryption but
not cinder will not work in the long run. The eventual result will be
that nova will have to take on most of the functionality of cinder and
we'll be back to the nova-volume days.
Could you explain further what you mean by "nova will have to take on most of 
the functionality of cinder"? In the current design, Nova is still passing data 
blocks to Cinder for storage – they're just encrypted instead of plaintext. 
That doesn't seem to subvert the functionality of Cinder or reimplement it.

Also in case it's not obvious, if you use different providers for
compute and storage, your performance is going to be absolutely terrible.
The general idea is probably separation of duties, which contradicts the 
original statement that "the cinder admin and the nova admin are ALWAYS the 
same people." Is there an operational reason that these admins must be the same 
person, or is that just typical?

Joel

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Is Live-migration not supported in CONF.libvirt.images_type=lvm case?

[Coffman, Joel M.]

I think you’re correct: it looks like the change you identified covers only the 
migrate code path but doesn’t address live migration. As identified in the 
comments on the bug report [1], it would be beneficial at least to raise to 
reasonable error message.

I also found an abandoned change for the bug: 
https://review.openstack.org/#/c/80029/

Joel


From: Rui Chen [mailto:chenrui.m...@gmail.com]
Sent: Friday, May 08, 2015 4:20 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [nova] Is Live-migration not supported in 
CONF.libvirt.images_type=lvm case?

Hi all:

I find the bug [1] block/live migration doesn't work with LVM as libvirt 
storage is marked as 'Fix released', but I don't think this issue really is 
solved, I check the live-migration code and don't find any logic for handling 
LVM disk. Please correct me if I'm wrong.

In the bug [1] comments, the only related merged patch is 
https://review.openstack.org/#/c/73387/ , it cover the 'resize/migrate' code 
path, not live-migration, and I don't think this bug [1] is duplicate with bug 
[2], they are the different use case, live-migration and migration.

So should we reopen this bug and add some documentation to describe that 
live-migration is not supported in current code?

[1]: https://bugs.launchpad.net/nova/+bug/1282643
[2]: https://bugs.launchpad.net/nova/+bug/1270305
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [barbican] Utilizing the KMIP plugin

[Coffman, Joel M.]

However, I cannot not make a request to the kmip plugin because of an ssl error:
The keyfile, certfile, and ca_certs are passed directly to ssl.wrap_socket. 
Debugging any SSL errors isn't easy - Google is generally the best resource to 
identify and resolve issues based on the error codes returned by OpenSSL. :-(

What exactly is each variable suppose to contain?
See the ssl.wrap_socket documentation for more details.
I have keyfile and certfile being a self signed certificate and 2048 bit RSA 
key respectively for barbican to use and ca_certs is the kmip_plugins' 
certificate for barbican to trust. Does this setup sound right?
In the sentence, you swap the key and certificate (i.e., the RSA key should be 
the keyfile and the self-signed certificate should be the certfile), but that's 
probably not the real issue. :-)

If credentials (i.e., a key and certificate) weren't provided to you for the 
KMIP appliance, you'll probably need to have the KMIP appliance sign your 
self-signed certificate so it knows that it's valid. The procedure differs by 
appliance but loosely resembles the following:

1.   Generate key and certificate on local machine using OpenSSL

2.   Upload certificate to KMIP appliance

3.   Sign the certificate using the KMIP appliance's server certificate
Alternatively, a key and certificate could be provided for the KMIP appliance; 
you would use those files rather than generating them locally.

Hope that information is helpful.

Joel


From: John Wood [mailto:john.w...@rackspace.com]
Sent: Wednesday, April 15, 2015 9:19 AM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Reller, Nathan S.; Farr, Kaitlin M.
Subject: Re: [openstack-dev] [barbican] Utilizing the KMIP plugin

Hello Christopher,

I'm glad you are making progress. I'm including two folks that worked on the 
KMIP plugin to see if they can help with your error diagnosis.

Thanks,
John


From: Christopher N Solis cnso...@us.ibm.commailto:cnso...@us.ibm.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Tuesday, April 14, 2015 at 10:21 AM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [barbican] Utilizing the KMIP plugin


Hey John.
Thanks!
You were right. It was reading the config from the /root directory because I 
switched to the root user.
After switching back to the normal user it is reading the correct config file 
again.
It is trying to use the kmip plugin now.

However, I cannot not make a request to the kmip plugin because of an ssl error:

2015-04-14 10:02:26,219 - barbican.plugin.kmip_secret_store - ERROR - Error 
opening or writing to client
Traceback (most recent call last):
  File /home/swift/barbican/barbican/plugin/kmip_secret_store.py, line 167, 
in generate_symmetric_key
self.client.open()
  File 
/home/swift/.pyenv/versions/barbican27/lib/python2.7/site-packages/kmip/services/kmip_client.py,
 line 86, in open
self.socket.connect((self.host, self.port))
  File /home/swift/.pyenv/versions/2.7.6/lib/python2.7/ssl.py, line 333, in 
connect
self._real_connect(addr, False)
  File /home/swift/.pyenv/versions/2.7.6/lib/python2.7/ssl.py, line 314, in 
_real_connect
self.ca_certs, self.ciphers)
SSLError: [Errno 0] _ssl.c:343: error::lib(0):func(0):reason(0)

I believe there is a problem in the KMIP plugin part of the barbican-api.conf 
file:
keyfile = '/path/to/certs/cert.key'
certfile = '/path/to/certs/cert.crt'
ca_certs = '/path/to/certs/LocalCA.crt'

What exactly is each variable suppose to contain?
I have keyfile and certfile being a self signed certificate and 2048 bit RSA 
key respectively for barbican to use and
ca_certs is the kmip_plugins' certificate for barbican to trust. Does this 
setup sound right?

Regards,
Christopher Solis

[Inactive hide details for John Wood ---04/10/2015 07:24:59 PM---Hello 
Christopher, It does seem that configs are being read for]John Wood 
---04/10/2015 07:24:59 PM---Hello Christopher, It does seem that configs are 
being read for another location. Try to remove that

From: John Wood john.w...@rackspace.commailto:john.w...@rackspace.com
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: 04/10/2015 07:24 PM
Subject: Re: [openstack-dev] [barbican] Utilizing the KMIP plugin





Hello Christopher,

It does seem that configs are being read for another location. Try to remove 
that copy in you home directory (so just keep the /etc location). If you see 
the same issue, try to rename your /etc/barbican/barbican-api.conf file to 
something else. Barbican should crash, probably with a No SQL connection error.

Also, double check the 'kmip_plugin' setting in setup.cfg as per below, and 

Re: [openstack-dev] [FFE] [nova] Barbican key manager wrapper

[Coffman, Joel M.]

-Original Message-
From: Sean Dague [mailto:s...@dague.net]
Sent: Friday, September 05, 2014 8:50 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [FFE] [nova] Barbican key manager wrapper



On 09/05/2014 08:11 AM, Sean Dague wrote:

 On 09/05/2014 07:51 AM, Daniel P. Berrange wrote:

 On Thu, Sep 04, 2014 at 05:19:45PM +, Coffman, Joel M. wrote:

 We request a feature freeze exception be granted to merge this code [3], 
 which is really a shim between the existing key manager interface in Nova 
 and python-barbicanclient, into Nova [4]. The acceptance of this feature 
 will improve the security of cloud users and operators who use the Cinder 
 volume encryption feature [1], which is currently limited to a single, 
 static encryption key for volumes. Cinder has already merged a similar 
 feature [5] following the review of several patch revisions; not accepting 
 the feature in Nova creates a disparity with Cinder in regards to the 
 management of encryption keys.

[snip]



There is a real issue in the current patch which I -1ed on Wed around the way 
requirements are pulled in.



If you are in FFE there really is an expectation that patches are respun 
quickly on feedback. So if this isn't addressed shortly, I'm removing my 
sponsorship here.



That feedback has been addressed - sorry for the delay.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [FFE] [nova] Barbican key manager wrapper

[Coffman, Joel M.]

A major concern about several encryption features within Nova [1, 2] has been 
the lack of secure key management. To address this concern, work has been 
underway to integrate these features with Barbican [3], which can be used to 
manage encryption keys across OpenStack.

We request a feature freeze exception be granted to merge this code [3], which 
is really a shim between the existing key manager interface in Nova and 
python-barbicanclient, into Nova [4]. The acceptance of this feature will 
improve the security of cloud users and operators who use the Cinder volume 
encryption feature [1], which is currently limited to a single, static 
encryption key for volumes. Cinder has already merged a similar feature [5] 
following the review of several patch revisions; not accepting the feature in 
Nova creates a disparity with Cinder in regards to the management of encryption 
keys.

As this is an optional feature that introduces very few changes to pre-existing 
code, the risk of disruption to existing deployments as well as the risk of 
regression is minimal. The only objection that has very recently been voiced is 
the implicit dependency on the Barbican service, which does not yet have 
experimental jobs in Tempest. Other core reviewers, though, believe that the 
existing unit tests included with the change are sufficient.

Thank you for taking the time to consider this request.

The APL Development Team

[1] https://blueprints.launchpad.net/nova/+spec/encrypt-cinder-volumes
[2] https://blueprints.launchpad.net/nova/+spec/lvm-ephemeral-storage-encryption
[3] https://review.openstack.org/#/c/104001/
[4] https://blueprints.launchpad.net/nova/+spec/encryption-with-barbican
[5] https://blueprints.launchpad.net/cinder/+spec/encryption-with-barbican


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OpenStack] [Barbican] Cinder and Barbican

[Coffman, Joel M.]

We are currently working to support Barbican for Cinder volume encryption. Some 
links to our work are as follows:
Blueprint: 
https://blueprints.launchpad.net/cinder/+spec/encryption-with-barbican
Specification: https://review.openstack.org/#/c/106437/ (needs approval from 
another Cinder core)
Implementation: https://review.openstack.org/#/c/106437/

Cheers,
Joel


From: Giuseppe Galeota [mailto:giuseppegale...@gmail.com]
Sent: Tuesday, July 22, 2014 11:39 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [OpenStack] [Barbican] Cinder and Barbican

Dear all,
is Cinder capable today to use Barbican for encryption? If yes, can you link to 
me some useful doc?

Thank you,
Giuseppe
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] key management and Cinder volume encryption

[Coffman, Joel M.]

The following change provides a key manager implementation that reads a static 
key from the project's configuration: https://review.openstack.org/#/c/45103/

This key manager implementation naturally does not provide the same 
confidentiality that would be proffered by retrieving keys from a service like 
Barbican or a KMIP server, but it still provides protection against certain 
attacks like intercepting iSCSI traffic between the compute and storage host 
and lost / stolen disks.


From: Bryan D. Payne [mailto:bdpa...@acm.org]
Sent: Wednesday, September 04, 2013 9:47 AM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [nova] key management and Cinder volume encryption


External dependencies are fine, obviously.  The difference is whether we
actually have code to interface with those external dependencies.  We
have code to talk to databases and message queues.  There's no code
right now to interface with anything for key management.

Ok, this makes sense.  I generally assume that people deploying OpenStack have 
some integration work to do anyway.  So, for me, writing a few python methods 
isn't much different than writing a configuration file.  Having said this, I do 
understand where you are coming from here.

I do believe that a static key configuration is a useful starting place for a 
lot of users.  I spoke with Joel this morning and I think he is going to try to 
put together an example key management driver that does this today.  Such a 
solution would allow deployers to use their existing orchestration tools to 
write a key to a configuration file.

Cheers,
-bryan
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] key management and Cinder volume encryption

[Coffman, Joel M.]

We have fully implemented support for transparently encrypting Cinder 
volumeshttps://blueprints.launchpad.net/nova/+spec/encrypt-cinder-volumes 
from within Nova (see  https://review.openstack.org/#/c/30976/), but the lack 
of a secure key manager within OpenStack currently precludes us from 
integrating our work with that piece of the overall architecture. Instead, a 
key manager interface (see  https://review.openstack.org/#/c/30973/) abstracts 
this interaction. We would appreciate the consideration of the Nova core team 
regarding merging our existing work because 1) there is nothing immediately 
available with which to integrate; 2) services such as 
Barbicanhttps://launchpad.net/cloudkeep/+announcements are on the path to 
incubation and alternative key management schemes (e.g., KMIP Client for volume 
encryption key 
managementhttps://blueprints.launchpad.net/nova/+spec/kmip-client-for-volume-encryption)
 have also been proposed; 3) we avoid the hassle of rebasing until the 
aforementioned services become available; and 4) our code does not directly 
depend upon a particular key manager but upon the aforementioned interface, 
which should be simple for key managers to implement. Furthermore, the current 
dearth of key management within OpenStack does not preclude the use of our 
existing work within a production environment; although the security is 
diminished, our implementation provides protection against certain attacks like 
intercepting the iSCSI communication between the compute and storage host.

Feedback regarding the possibility of merging our work would be appreciated.

Joel
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev