Open Stack

Hello Everyone!

Just wanted to let you know that the key manager folks are busy ..

Our postings to the mailing list will have the subject prefix: [openstack-dev] [barbican]
Freenode IRC hangout:  '#openstack-cloudkeep'
Wiki https://github.com/cloudkeep/barbican/wiki/_pages


Early developers and adoptors:
John Wood john.wood at RACKSPACE.COM<mailto:john.wood at RACKSPACE.COM>
Douglas Mendizabal <douglas.mendizabal at RACKSPACE.COM<mailto:douglas.mendizabal at RACKSPACE.COM>>;
Andrew Hartnett andrew.hartnett at RACKSPACE.COM<mailto:andrew.hartnett at RACKSPACE.COM>
Jarret Raim jarret.raim at RACKSPACE.COM<mailto:jarret.raim at RACKSPACE.COM>;
Malini Bhandaru malini.k.bhandaru at intel.com<mailto:malini.k.bhandaru at intel.com>
Reller, Nathan S. <Nathan.Reller at jhuapl.edu<mailto:Nathan.Reller at jhuapl.edu>>;
Coffman, Joel M. <Joel.Coffman at jhuapl.edu<mailto:Joel.Coffman at jhuapl.edu>>;
Glendenning, Laura J. <Laura.Glendenning at jhuapl.edu<mailto:Laura.Glendenning at jhuapl.edu>>;
Nate Reller (rellerreller at yahoo.com<mailto:rellerreller at yahoo.com>);
Benjamin, Bruce P. <Bruce.Benjamin at jhuapl.edu<mailto:Bruce.Benjamin at jhuapl.edu>>

Meeting minutes from today, April 26, 2013
.

1)      Acknowledged: team has a common goal of getting volume encryption and key manager into Havana.

  Volume encryption needs key management

  Key manager needs a user and demonstrate integration

2)      Goal: July 18, 2013 incubation target for Havana. Need a stable, minimally functional, integrated implementation.

3)      API:  create_key (optional args: type, length)
                           Returns key-id, and key-string
                           First cut: symmetric key

                           (Stub API implementation could return the exact same string for all key-ids)
               Get_key (key-id), returns key-string
                Delete_key

4)      Client for key manager   -- ala python-barbican_client

  Data formats json and xml.

  Initial json

5)      Defer tackling split-keys, user holding a part, or user part domain/project/etc specific in keystone or ..

6)      Flesh out concept of key-access.  We could separate owner and delegated-access aspects.

  A key could have delegated-access = {Nova-compute, swift, cinder ..} etc  typically openstack services

                             Scope-access = domain/project(s)/user

Through keystone delegation, limit access time to keys and which keys

7)     Meta data:

Cinder will hold meta data with volume regarding key-id, algorithm etc

Current thinking how key is used and where, can be key agnostic (will revisit later if necessary based on use case convulsions, JHU_APL at this point fine with this.)

8)   First cut: supporting above API. How the encryption, random keys etc generate, all internal. An HSM, a KMIP implementation whatever.

9)    First cut, users can pull functionality from git and have their own service instance, ala devstack one-all-in-box model or other.  Will speed integration effort.

10)   TODO - move code into sourceforge to take advantage of the code review, build and other tools

11)   Questions:

a)      What auth tokens that come along with a request - user only? Delegated-user?  (learn more from OpenStack and Keystone folks)

b)      Token expiration- what happens if primary user token is 24 hrs. long and a volume request comes in the last minute and falls on the edge of expiration during the process

c)      JHU-APL to discuss and learn more about KMIP requirements from their sponsor.

d)      Later on - for an open key management system might want to request some port number like keystone with IANA

e)      Maintaining re-key history

  Event logs would contain it but elsewhere?  if yes, what ..

f)       Is there any OpenStack requirement that a product needs to support Python 2.6 too. Most of the projects seem to mention Python 2.6.

g)      Should keys maintain a URI to the object they wrap - from a security point may be not, some opacity is nice!!

Adds a layer of work in that if a resource moves, we need some other middleware to transparently take care of the mapping. First cut - not supporting.

h)      Volumes --  At point of attach, through horizon UI specify encryption yes/no, algorithm etc. May  be later this could be part of user preference.





Regards

John, Jarret & Malini






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130426/a880aee5/attachment.html>