Open Stack

> 
>It seems KMIP is getting lots of enterprise attention, so I think it may
>be good candidate for future (as you already mentioned in your email
>below) Barbican feature,  as per the link below it seems our community
>also expects KMIP to be integrated with OpenStack line of products.
> 
>https://wiki.openstack.org/wiki/KMIPclient

I have heard the interest in KMIP stated several times at the Summit and
on this list. However, I've talked with many large customers and they are
not asking me for KMIP support right now. I think we will support it at
some point in the future, but as there is no python lib, it is a
reasonably large undertaking to build one correctly. If anyone wants to
help with that, we'd love to have you.

On that blueprint, it was only written a week ago. I already posted a
message on why I think implementing KMIP directly into products is a bad
idea, but any project can go whichever way works best for their users.

> 
>Would you mind sharing the Barbican product roadmap (if it is public) as
>I did not find one?

Most of our work is aimed at cleaning up the current features for Havana.
We are cleaning up the API's treatment of content-types and implementing
backend support for various key storage devices (HSMs, etc) and building
out our production environment at Rackspace. Additionally, we have a lot
of 'good citizen' stuff to finish up including usage events, auditing and
some other features.

Going forward, there are some large feature sets we are looking to build
including SSL support (automatic provisioning, lifecycle management) and
federation. I'm hoping we'll get some more good feedback from customers
once we launch, so I'm leaving some room in the roadmap for requests that
may come up.

> 
>Following are some of thoughts on your previous email about KMIP
>
>(*) That is true but it is getting lots of recognition which means in
>future we will see more HSM product with KMIP compatibility.

There are certainly some out there. As they become more popular, we'll
certainly become more interested in supporting them. The key here is that
HSMs can be supported just fine right now using existing libs and PKCS
#11. Until there is a compelling reason to switch to KMIP, I don't see a
lot of effort going there from us.

>(**) I think Barbican will act as a KMS proxy in this case, which does
>not fulfill the KMIP protocol philosophy which build around interaction
>between KMIP client and server.

As I've said before, I don't think expecting products to talk directly
with the KMIP server is realistic. There are a mountain of tasks that a
good openstack service is expected to do including using keystone for
authentication, providing centrally managed RBAC and access control,
providing metrics events to ceilometer, speaking ReST / JSON, scaling from
small private cloud to large public clouds and many more. KMIP servers
will most likely never do those things. It will be much easier to have
openstack speak a to common, restful, open source abstraction. Underneath,
we can deal with the various key storage styles.

>From what I've seen, KMIP doesn't really support the true multi tenancy
use cases such as those needed by Rackspace. I'm would happy to be proven
wrong, but right now this fact makes it impossible for an OpenStack to use
the device directly as Barbican is needed to provide tenant isolation and
authentication. If Barbican wasn't there, every product will need to
understand the HSM model, be able to configure it as needed and submit to
whatever authentication mechanism is required. This means that the choice
of an HSM vendor will leak out into all the services in a deployment,
rather than just the one that needs to deal with it.

Finally, there must be a free and open source implementation for key
management. Not all providers are interested or capable of purchasing HSMs
to back their encryption and are okay with that tradeoff. PKCS and KMIP
have been around for a while now and we've seen almost no adoption outside
of the enterprise and usually just between large enterprise software
packages. I want strong encryption and key management to be easy for
developers to integrate into all software. It needs to be free,
open-source and dev friendly, none of which describes the current state of
the art. Barbican is going to provide key management to openstack and we
hope that other projects will integrate with us. We will also provide key
management directly to customers to ensure that everyone can build strong
data protection into their applications.

Now if we can just get HSM vendors to install Barbican on their devices,
maybe we'd have something :)


Thanks,
Jarret



> 
> 
>Regards,
>Arvind
> 
> 
> 
>From: Jarret Raim [mailto:jarret.raim at RACKSPACE.COM]
>
>Sent: Monday, July 22, 2013 2:38 PM
>To: OpenStack Development Mailing List
>Subject: Re: [openstack-dev] [barbican]
>
>
> 
>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.raim at rackspace.com <mailto:jarret.raim at 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.tiwari at 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
><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
><https://www.oasis-open.org/standards#kmipspecv1.1>) complaint? If not,
>what are the plans any initiative so far?
>
> 
> 
>Thanks,
>Arvind
>