I'm the product owner for Barbican at Rackspace. I'll take a shot an answering your questions.
> 1. What is the state of the project, is it in the state where it can be > utilized in production deployments? We currently in active development and pushing for our 1.0 release for Havana. As to production deployments, the answer right now is none. We are currently working on enabling Barbican to use hardware security modules for key storage. Once this code is complete, we should be close to a place where the first production deployment is feasible. At Rack, we are building out the infrastructure to do so and I hope to have good news once we get towards the Summit. > 2. Dose Barbican is an implementation of > https://wiki.openstack.org/wiki/KeyManager BP? If not please point me to the > correct design/BP resource on which Barbican is based on. We are inspired by the blueprint you linked. That blueprint was a bit more limited than we were planning and we have changed quite a bit. For a more detailed version, you can find lots of documentation on our wiki here: https://github.com/cloudkeep/barbican/wiki/Blueprint:-Technical-Approach https://github.com/cloudkeep/barbican https://github.com/cloudkeep/barbican/wiki > 3. Is it KMIP (KMIP 1.1 spec > https://www.oasis-open.org/standards#kmipspecv1.1) complaint? If not, what > are the plans any initiative so far? Not right now. As I mentioned in a previous email (I'll copy the contents below), KMIP is not the greatest protocol for this use case. Our current plans are to expose the Barbican API to all consumers. This is a standard OpenStack API using ReST / JSON, authing through keystone, etc. If there is enough interest, I am planning on supporting KMIP inside Barbican to talk to various HSM type providers. This would most likely not be exposed to customers. I haven't heard from anyone who needs KMIP support at this point. Mostly the questions have just been whether we are planning on supporting it. If you have a strong use case as to why you want / need it, I'd love to hear it. You can respond here or reach out to me at jarret.r...@rackspace.com<mailto:jarret.r...@rackspace.com> Thanks, Jarret Here is the previous email relating to KMIP for additional reading: I'm not sure that I agree with this direction. In our investigation, KMIP is a problematic protocol for several reasons: * We haven't found an implementation of KMIP for Python. (Let us know if there is one!) * Support for KMIP by HSM vendors is limited. * We haven't found software implementations of KMIP suitable for use as an HSM replacement. (e.g. Most deployers wanting to use KMIP would have to spend a rather large amount of money to purchase HSMs) * From our research, the KMIP spec and implementations seem to lack support for multi-tenancy. This makes managing keys for thousands of users difficult or impossible. The goal for the Barbican system is to provide key management for OpenStack. It uses the standard interaction mechanisms for OpenStack, namely ReST and JSON. We integrate with keystone and will provide common features like usage events, role-based access control, fine grained control, policy support, client libs, Celiometer support, Horizon support and other things expected of an OpenStack service. If every product is forced to implement KMIP, these features would most likely not be provided by whatever vendor is used for the Key Manager. Additionally, as mentioned in the blueprint, I have concerns that vendor specific data will be leaked into the rest of OpenStack for things like key identifiers, authentication and the like. I would propose that rather than each product implement KMIP support, we implement KMIP support into Barbican. This will allow the products to speak ReST / JSON using our client libraries just like any other OpenStack system and Barbican will take care of being a good OpenStack citizen. On the backend, Barbican will support the use of KMIP to talk to whatever device the provider wishes to deploy. We will also support other interaction mechanisms including PKCS through OpenSSH, a development implementation and a fully free and open source software implementation. This also allows some advanced uses cases including federation. Federation will allow customers of public clouds like Rackspace's to maintain custody of their keys while still being able to delegate their use to the Cloud for specific tasks. I've been asked about KMIP support at the Summit and by several of Rackspace's partners. I was planning on getting to it at some point, probably after Icehouse. This is mostly due to the fact that we didn't find a suitable KMIP implementation for Python so it looks like we'd have to write one. If there is interest from people to create that implementation, we'd be happy to help do the work to integrate it into Barbican. We just released our M2 milestone and we are on track for our 1.0 release for Havana. I would encourage anyone interested to check our what we are working on and come help us out. We use this list for most of our discussions and we hang out on #openstack-cloudkeep on free node. From: Tiwari, Arvind [mailto:arvind.tiw...@hp.com] Sent: Monday, July 22, 2013 11:22 AM To: OpenStack Development Mailing List Subject: [openstack-dev] [barbican] Hi All, I am following Barbican project and I have some question around it, I would appreciate if someone can answer them or point me to the correct resource 1. What is the state of the project, is it in the state where it can be utilized in production deployments? 2. Dose Barbican is an implementation of https://wiki.openstack.org/wiki/KeyManager BP? If not please point me to the correct design/BP resource on which Barbican is based on. 3. Is it KMIP (KMIP 1.1 spec https://www.oasis-open.org/standards#kmipspecv1.1) complaint? If not, what are the plans any initiative so far? Thanks, Arvind
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
