Re: [openstack-dev] [nova] key management and Cinder volume encryption
On 09/03/2013 09:27 PM, Bryan D. Payne wrote: How can someone use your code without a key manager? Some key management mechanism is required although it could be simplistic. For example, we’ve tested our code internally with an implementation of the key manager interface that returns a single, constant key. That works for testing but doesn't address: the current dearth of key management within OpenStack does not preclude the use of our existing work within a production environment My understanding here is that users are free to use any key management mechanism that they see fit. This can be a simple return a static key option. Or it could be using something more feature rich like Barbican. Or it could be something completely home grown that is suited to a particular OpenStack deployment. I don't understand why we are getting hung up on having a key manager as part of OpenStack in order to accept this work. Clearly there are other pieces of OpenStack that have external dependencies (message queues, to name one). 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. The request here is for something that allows this to be used without having to modify or add code to Nova. I, for one, am looking forward to using this feature and would be very disappointed to see it pushed back for yet another release. It's not like I'm happy about it, but it needs more code. Is a feature complete if no one can use it? I am happy with a less then secure but fully functional key manager. But with no key manager that can be used in a real deployment, what is the value of including this code? Of course people can use it. They just need to integrate with some solution of the deployment's choosing that provides key management capabilities. And, of course, if you choose to not use the volume encryption then you don't need to worry about it at all. As noted above, the integration effort takes code. We need that code so that the feature can be used. I've watched this feature go through many, many iterations throughout both the Grizzly and Havana release cycles. The authors have been working hard to address everyone's concerns. In fact, they have navigated quite a gauntlet to get this far. And what they have now is an excellent, working solution. Let's accept this nice security enhancement and move forward. I agree that they have worked hard. It's much appreciated. We have held other features to this same standard. See the discussion about live snapshots / cloning fairly recently for one such example. We require that there be code in the tree that makes the feature usable. That's where we are with this. If a simple return a static key is deemed useful, I suspect that could be put together in time. From talking to Joel on IRC, it seemed that it wasn't worth it. This is one of those cases where we have to make a tough call, but after reviewing the concerns raised, the answer is that without some additional code to make it usable without modifications or additions, the feature is deferred to Icehouse. -- Russell Bryant ___ 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
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
Re: [openstack-dev] [nova] key management and Cinder volume encryption
On Tue, Sep 3, 2013 at 4:38 PM, Coffman, Joel M. joel.coff...@jhuapl.eduwrote: We have fully implemented support for transparently encrypting Cinder volumeshttps://blueprints.launchpad.net/nova/+spec/encrypt-cinder-volumesfrom 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/+announcementsare 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. ** How can someone use your code without a key manager? ** 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 ___ 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
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
Re: [openstack-dev] [nova] key management and Cinder volume encryption
On Tue, Sep 3, 2013 at 5:41 PM, Coffman, Joel M. joel.coff...@jhuapl.eduwrote: How can someone use your code without a key manager? Some key management mechanism is required although it could be simplistic. For example, we’ve tested our code internally with an implementation of the key manager interface that returns a single, constant key. That works for testing but doesn't address: the current dearth of key management within OpenStack does not preclude the use of our existing work within a production environment ** ** I think the underlying issue is how to handle interrelated features – if Nova doesn’t want to accept the volume encryption feature without a full-fledged key manager, then why accept a key manager (or its interface stubs) unless it already has a feature that requires it (e.g., volume encryption)? And round-and-round it goes. You can propose both patches at the same time one being dependent on the other, so we can merge both at the same time ** ** I’d also like to point out that the volume encryption feature is “complete” and won’t require changes when a full-fledged key manager becomes available. All that’s needed is to specify the key manager via a configuration option. So this request is definitely **not** a case of trying to land a feature that isn’t finished and is disabled by default (see [1], [2], and [3]). Is a feature complete if no one can use it? I am happy with a less then secure but fully functional key manager. But with no key manager that can be used in a real deployment, what is the value of including this code? ** ** [1] http://lists.openstack.org/pipermail/openstack-dev/2013-April/008244.html* *** [2] http://lists.openstack.org/pipermail/openstack-dev/2013-April/008315.html* *** [3] http://lists.openstack.org/pipermail/openstack-dev/2013-April/008268.html* *** ** ** ** ** *From:* Joe Gordon [mailto:joe.gord...@gmail.com] *Sent:* Tuesday, September 03, 2013 4:48 PM *To:* OpenStack Development Mailing List *Subject:* Re: [openstack-dev] [nova] key management and Cinder volume encryption ** ** ** ** ** ** On Tue, Sep 3, 2013 at 4:38 PM, Coffman, Joel M. joel.coff...@jhuapl.edu wrote: We have fully implemented support for transparently encrypting Cinder volumeshttps://blueprints.launchpad.net/nova/+spec/encrypt-cinder-volumesfrom 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/+announcementsare 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. ** ** How can someone use your code without a key manager? ** ** 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 ** ** ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ 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
The issue here is the key manager, barbican, under development is in incubation. Folks can download and use barbican. The barbican team has worked deligently to produce the system. In fact, folks can download and use and vote for Joel's patch to be merged. And do give us feedback on barbican. The chicken-egg problem .. and the desire to keep the key manager as a separate service entails the incubation requirement. Regards Malini From: Joe Gordon [joe.gord...@gmail.com] Sent: Tuesday, September 03, 2013 6:06 PM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [nova] key management and Cinder volume encryption On Tue, Sep 3, 2013 at 5:41 PM, Coffman, Joel M. joel.coff...@jhuapl.edumailto:joel.coff...@jhuapl.edu wrote: How can someone use your code without a key manager? Some key management mechanism is required although it could be simplistic. For example, we’ve tested our code internally with an implementation of the key manager interface that returns a single, constant key. That works for testing but doesn't address: the current dearth of key management within OpenStack does not preclude the use of our existing work within a production environment I think the underlying issue is how to handle interrelated features – if Nova doesn’t want to accept the volume encryption feature without a full-fledged key manager, then why accept a key manager (or its interface stubs) unless it already has a feature that requires it (e.g., volume encryption)? And round-and-round it goes. You can propose both patches at the same time one being dependent on the other, so we can merge both at the same time I’d also like to point out that the volume encryption feature is “complete” and won’t require changes when a full-fledged key manager becomes available. All that’s needed is to specify the key manager via a configuration option. So this request is definitely *not* a case of trying to land a feature that isn’t finished and is disabled by default (see [1], [2], and [3]). Is a feature complete if no one can use it? I am happy with a less then secure but fully functional key manager. But with no key manager that can be used in a real deployment, what is the value of including this code? [1] http://lists.openstack.org/pipermail/openstack-dev/2013-April/008244.html [2] http://lists.openstack.org/pipermail/openstack-dev/2013-April/008315.html [3] http://lists.openstack.org/pipermail/openstack-dev/2013-April/008268.html From: Joe Gordon [mailto:joe.gord...@gmail.commailto:joe.gord...@gmail.com] Sent: Tuesday, September 03, 2013 4:48 PM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [nova] key management and Cinder volume encryption On Tue, Sep 3, 2013 at 4:38 PM, Coffman, Joel M. joel.coff...@jhuapl.edumailto:joel.coff...@jhuapl.edu wrote: 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. How can someone use your code without a key manager? Feedback regarding the possibility of merging our work would be appreciated. Joel ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman
Re: [openstack-dev] [nova] key management and Cinder volume encryption
On 09/03/2013 05:41 PM, Coffman, Joel M. wrote: How can someone use your code without a key manager? Some key management mechanism is required although it could be simplistic. For example, we’ve tested our code internally with an implementation of the key manager interface that returns a single, constant key. I understand Joe's concern. I've used a similar argument to turn down other features. I generally want *everything* we merge to be usable with the code in the tree. If it's not usable, I push to have it wait until it is. In this case, it's obviously something we should have caught and brought up earlier. If there is any possible way a simple implementation of the key manager interface could be included, then that could probably save this for Havana. We could consider a feature freeze exception to give it a few extra days, but not more than that. Otherwise, as much as I really hate to say it, this will probably have to get deferred. -- Russell Bryant ___ 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
On 09/03/2013 06:26 PM, Bhandaru, Malini K wrote: The issue here is the key manager, barbican, under development is in incubation. Folks can download and use barbican. The barbican team has worked deligently to produce the system. In fact, folks can download and use and vote for Joel's patch to be merged. And do give us feedback on barbican. The chicken-egg problem .. and the desire to keep the key manager as a separate service entails the incubation requirement. Couple of things... Barbican is not yet in incubation. That is an official project status that must be applied for and is reviewed by the OpenStack Technical Committee. Even if it was, we don't have a patch ready to go along with this feature to make use of the Barbican API. -- Russell Bryant ___ 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
How can someone use your code without a key manager? Some key management mechanism is required although it could be simplistic. For example, we’ve tested our code internally with an implementation of the key manager interface that returns a single, constant key. That works for testing but doesn't address: the current dearth of key management within OpenStack does not preclude the use of our existing work within a production environment My understanding here is that users are free to use any key management mechanism that they see fit. This can be a simple return a static key option. Or it could be using something more feature rich like Barbican. Or it could be something completely home grown that is suited to a particular OpenStack deployment. I don't understand why we are getting hung up on having a key manager as part of OpenStack in order to accept this work. Clearly there are other pieces of OpenStack that have external dependencies (message queues, to name one). I, for one, am looking forward to using this feature and would be very disappointed to see it pushed back for yet another release. Is a feature complete if no one can use it? I am happy with a less then secure but fully functional key manager. But with no key manager that can be used in a real deployment, what is the value of including this code? Of course people can use it. They just need to integrate with some solution of the deployment's choosing that provides key management capabilities. And, of course, if you choose to not use the volume encryption then you don't need to worry about it at all. I've watched this feature go through many, many iterations throughout both the Grizzly and Havana release cycles. The authors have been working hard to address everyone's concerns. In fact, they have navigated quite a gauntlet to get this far. And what they have now is an excellent, working solution. Let's accept this nice security enhancement and move forward. Cheers, -bryan ___ 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
On Tue, Sep 3, 2013 at 7:27 PM, Bryan D. Payne bdpa...@acm.org wrote: How can someone use your code without a key manager? Some key management mechanism is required although it could be simplistic. For example, we’ve tested our code internally with an implementation of the key manager interface that returns a single, constant key. That works for testing but doesn't address: the current dearth of key management within OpenStack does not preclude the use of our existing work within a production environment My understanding here is that users are free to use any key management mechanism that they see fit. This can be a simple return a static key option. Or it could be using something more feature rich like Barbican. Or it could be something completely home grown that is suited to a particular OpenStack deployment. I don't understand why we are getting hung up on having a key manager as part of OpenStack in order to accept this work. Clearly there are other pieces of OpenStack that have external dependencies (message queues, to name one). I, for one, am looking forward to using this feature and would be very disappointed to see it pushed back for yet another release. Is a feature complete if no one can use it? I am happy with a less then secure but fully functional key manager. But with no key manager that can be used in a real deployment, what is the value of including this code? Of course people can use it. They just need to integrate with some solution of the deployment's choosing that provides key management capabilities. And, of course, if you choose to not use the volume encryption then you don't need to worry about it at all. I've watched this feature go through many, many iterations throughout both the Grizzly and Havana release cycles. The authors have been working hard to address everyone's concerns. In fact, they have navigated quite a gauntlet to get this far. And what they have now is an excellent, working solution. Let's accept this nice security enhancement and move forward. Cheers, -bryan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Do you have any docs or guides describing a reference implementation that would be able to use this in the manner you describe? ___ 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
On Tue, Sep 3, 2013 at 6:44 PM, John Griffith john.griff...@solidfire.comwrote: On Tue, Sep 3, 2013 at 7:27 PM, Bryan D. Payne bdpa...@acm.org wrote: How can someone use your code without a key manager? Some key management mechanism is required although it could be simplistic. For example, we’ve tested our code internally with an implementation of the key manager interface that returns a single, constant key. That works for testing but doesn't address: the current dearth of key management within OpenStack does not preclude the use of our existing work within a production environment My understanding here is that users are free to use any key management mechanism that they see fit. This can be a simple return a static key option. Or it could be using something more feature rich like Barbican. Or it could be something completely home grown that is suited to a particular OpenStack deployment. I don't understand why we are getting hung up on having a key manager as part of OpenStack in order to accept this work. Clearly there are other pieces of OpenStack that have external dependencies (message queues, to name one). As Russell so eloquently said I generally want *everything* we merge to be usable with the code in the tree That doesn't mean something cannot have external dependencies, it just needs to be usable with the external dependencies and no additional integration work should be required. I, for one, am looking forward to using this feature and would be very disappointed to see it pushed back for yet another release. Is a feature complete if no one can use it? I am happy with a less then secure but fully functional key manager. But with no key manager that can be used in a real deployment, what is the value of including this code? Of course people can use it. They just need to integrate with some solution of the deployment's choosing that provides key management capabilities. And, of course, if you choose to not use the volume encryption then you don't need to worry about it at all. I've watched this feature go through many, many iterations throughout both the Grizzly and Havana release cycles. The authors have been working hard to address everyone's concerns. In fact, they have navigated quite a gauntlet to get this far. And what they have now is an excellent, working solution. Let's accept this nice security enhancement and move forward. Cheers, -bryan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Do you have any docs or guides describing a reference implementation that would be able to use this in the manner you describe? ++ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
