Re: [openstack-dev] [Barbican] Nominating Steve Heyman for barbican-core

[Jarret Raim]

+1 for me as well.

From: Douglas Mendizabal 
mailto:douglas.mendiza...@rackspace.com>>
Reply-To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, November 5, 2014 at 4:29 PM
To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Barbican] Nominating Steve Heyman for 
barbican-core

+1

Douglas Mendizábal
IRC: redrobot
PGP Key: 245C 7B6F 70E9 D8F3 F5D5 0CC9 AD14 1F30 2D58 923C

From: Chad Lung mailto:chad.l...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, November 5, 2014 at 4:17 PM
To: 
"openstack-dev@lists.openstack.org" 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [Barbican] Nominating Steve Heyman for barbican-core

Greetings ,

I would like to nominate Steve Heyman for the barbican-core team.

Steve is very active in Barbican code reviews and has been a regular 
contributor of test related change requests as well as documentation.

As a reminder to barbican-core members, we use the voting process outlined in 
https://wiki.openstack.org/wiki/Barbican/CoreTeam to add members to our team.

Thanks,

Chad Lung

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

Re: [openstack-dev] [Barbican] Nominating Juan Antonio Osorio Robles for barbican-core

[Jarret Raim]

+1 for me.

From: Douglas Mendizabal 
mailto:douglas.mendiza...@rackspace.com>>
Reply-To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, November 5, 2014 at 4:53 PM
To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [Barbican] Nominating Juan Antonio Osorio Robles for 
barbican-core

Hi All,

I would like to nominate Juan Antonio Osorio Robles to the barbican-core team.

Juan has been consistently giving us very well thought out and constructive 
reviews for Barbican, python-barbicanclient and barbican-specs.  It’s obvious 
from his reviews that he cares deeply for the quality of the Barbican project, 
and I think he will be a great addition to the core team.

As a reminder to barbican-core members, we use the voting process outlined in 
https://wiki.openstack.org/wiki/Barbican/CoreTeam to add members to our team.

References:

http://stackalytics.com/report/contribution/barbican-group/90

Thanks,
Douglas


Douglas Mendizábal
IRC: redrobot
PGP Key: 245C 7B6F 70E9 D8F3 F5D5 0CC9 AD14 1F30 2D58 923C
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Barbican] PTL for Barbican

[Jarret Raim]

All,


It has been my pleasure to lead the Key Management program and Barbican
over the last year and a half. I'm proud of the work we have done, the
problems we are solving and the community that has developed around the
project. 

It should be no surprise to our community members that my day job has
pulled me further and further away from Barbican on a day to day basis. It
is for this reason that I am planning to step down as PTL for the program.

Thankfully, I've had great support from my team as Douglas Mendizabal has
stepped in to help with many of my PTL duties. He's been running our
weekly meetings, releases and shepparding specs through for a good chunk
of the Juno release cycle. Simply put, without his hard work, we wouldn't
have made the progress we have made for this release.

I encourage all our community members to support Douglas. He has my full
endorsement and I'm confident he is the right person to lead us through
the Kilo cycle, graduation and the first public Cloud deployment of
Barbican at Rackspace.



Thanks,

--
Jarret Raim 
@jarretraim




smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [barbican] Nominating Ade Lee for barbican-core

[Jarret Raim]

+1 for me as well.

Jarret

From:  Douglas Mendizabal 
Reply-To:  OpenStack List 
Date:  Thursday, July 10, 2014 at 11:55 AM
To:  OpenStack List , "a...@redhat.com"

Subject:  [openstack-dev] [barbican] Nominating Ade Lee for barbican-core

> Hi Everyone,
> 
> I would like to nominate Ade Lee for the barbican-core team.
> 
> Ade has been involved in the development of Barbican since January of this
> year, and he¹s been driving the work to enable DogTag to be used as a back end
> for Barbican.  Ade¹s input to the design of barbican has been invaluable, and
> his reviews are always helpful, which has earned him the respect of the
> existing barbican-core team.
> 
> As a reminder to barbican-core members, we use the voting process outlined in
> https://wiki.openstack.org/wiki/Barbican/CoreTeam to add members to our team.
> 
> Thanks,
> Doug
> 
> 
> Douglas Mendizábal
> IRC: redrobot
> PGP Key: 245C 7B6F 70E9 D8F3 F5D5 0CC9 AD14 1F30 2D58 923C




smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [barbican] Nominating Nathan Reller for barbican-core

[Jarret Raim]

+1 for me.

Jarret

From:  Douglas Mendizabal 
Reply-To:  OpenStack List 
Date:  Thursday, July 10, 2014 at 12:11 PM
To:  OpenStack List , Nate Reller

Subject:  [openstack-dev] [barbican] Nominating Nathan Reller for
barbican-core

> Hi Everyone,
> 
> I would also like to nominate Nathan Reller for the barbican-core team.
> 
> Nathan has been involved with the Key Management effort since early 2013.
> Recently, Nate has been driving the development of a KMIP backend for
> Barbican, which will enable Barbican to be used with KMIP devices.  Nate¹s
> input to the design of the plug-in mechanisms in Barbican has been extremely
> helpful, as well as his feedback in CR reviews.
> 
> As a reminder to barbican-core members, we use the voting process outlined in
> https://wiki.openstack.org/wiki/Barbican/CoreTeam to add members to our team.
> 
> Thanks,
> Doug
> 
> 
> Douglas Mendizábal
> IRC: redrobot
> PGP Key: 245C 7B6F 70E9 D8F3 F5D5 0CC9 AD14 1F30 2D58 923C




smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Barbican Meeting CANCELLED

[Jarret Raim]

All,

This week is Barbican's mid-cycle meet up. As many of our contributors are
in San Antonio this week, I'm going to cancel our weekly meeting today.

Several of us are still on IRC, so if you need something from us, feel
free to pop into #openstack-barbican and ask.

The etherpad being used for the meet up is here:

https://etherpad.openstack.org/p/barbican-juno-meetup






Thanks,
Jarret


smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Barbican] Barebones CA

[Jarret Raim]

Rob,

RedHat is working on a backend for Dogtag, which should be capable of
doing something like that. That's still a bit hard to deploy, so it would
make sense to extend the 'dev' plugin to include those features.


Jarret


On 6/24/14, 4:04 PM, "Clark, Robert Graham"  wrote:

>Yeah pretty much.
>
>That¹s something I¹d be interested to work on, if work isn¹t ongoing
>already.
>
>-Rob
>
>
>
>
>
>On 24/06/2014 18:57, "John Wood"  wrote:
>
>>Hello Robert,
>>
>>I would actually hope we have a self-contained certificate plugin
>>implementation that runs 'out of the box' to enable certificate
>>generation orders to be evaluated and demo-ed on local boxes.
>>
>>Is this what you were thinking though?
>>
>>Thanks,
>>John
>>
>>
>>
>>
>>From: Clark, Robert Graham [robert.cl...@hp.com]
>>Sent: Tuesday, June 24, 2014 10:36 AM
>>To: OpenStack List
>>Subject: [openstack-dev] [Barbican] Barebones CA
>>
>>Hi all,
>>
>>I¹m sure this has been discussed somewhere and I¹ve just missed it.
>>
>>Is there any value in creating a basic ŒCA¹ and plugin to satisfy
>>tests/integration in Barbican? I¹m thinking something that probably
>>performs OpenSSL certificate operations itself, ugly but perhaps useful
>>for some things?
>>
>>-Rob
>>
>>___
>>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


smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Barbican][OSSG][Keystone] Mid-Cycle Meetup

[Jarret Raim]

All,

There was some interest at the Summit in semi-combining the mid-cycle meet
ups for Barbican, Keystone and the OSSG as there is some overlap in team
members and interest areas. The current dates being considered are:

Mon, July 7 - Barbican
Tue, July 8 - Barbican
Wed, July 9 - Barbican / Keystone
Thu, July 10 - Keystone
Fri, July 11 - Keystone

Assuming these dates work for for everyone, we'll fit some OSSG work in
during whatever days make the most sense. The current plan is to have the
meet up in San Antonio at the new Geekdom location, which is downtown.
This should make travel a bit easier for everyone as people won't need
cars are there are plenty of hotels and restaurants within walking / short
cab distance.

I wanted to try to get a quick head count from the Barbican and OSSG folks
(I think Dolph already has one for Keystone). I'd also like to know if you
are a Barbican person interested in going to the Keystone sessions or vice
versa.

Once we get a rough head count estimate, Dolph and I can work on getting
everything booked.





Thanks,

--
Jarret Raim 
@jarretraim




smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Barbican] Meeting time moving?

[Jarret Raim]

We have not changed anything as of yet. The goal was to see if we could
find some times that work for Jamie, but I haven't done it yet. I'll post
something this week and we'll see if there is consensus.


Thanks,

--
Jarret Raim 
@jarretraim





On 5/20/14, 9:22 AM, "Clark, Robert Graham"  wrote:

>Hi All,
>
>At the summit I heard that the Barbican meeting time might be moving,
>has anything been agreed?
>
>Cheers
>-Rob
>


smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Barbican] Today's Meeting Cancelled

[Jarret Raim]

Barbicaneers,

Many of us are just getting back into the swing of things so we are going
to go ahead and cancel the meeting today. The main topic to be discussed
is our switch to using Gerrit for blueprints. The process is mostly
derived from Nova and is documented here:

https://wiki.openstack.org/wiki/Barbican/Blueprints


The proposed template for blueprints is here:

https://github.com/jarretraim/barbican-specs/blob/master/specs/template.rst



Please take a look at those and let me know if you see any problems.
Several of us will be on the #openstack-barbican channel if there are
issues to discuss.



Thanks!

--
Jarret Raim 
@jarretraim




smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] [barbican] Protecting user specific secrets in Barbican

[Jarret Raim]

I just spoke with Dolph and he suggested an option that seems to solve the
problem.

In Keystone, projects that belong to domains (or other projects as the
hierarchy work moves forward) can be marked as Private, which will prevent
any role inheritance for users higher in the hierarchy.

This seems to solve the stated use case?

Arvind - does this work for you?


Thanks,
Jarret


From:  Jarret Raim 
Reply-To:  OpenStack List 
Date:  Thursday, May 15, 2014 at 11:40 AM
To:  OpenStack List 
Cc:  "Chan, Tim" , "Jones, Brant" ,
Morgan Fainberg , "Thyne, Bob" 
Subject:  Re: [openstack-dev] [keystone] [barbican] Protecting user specific
secrets in Barbican

> So let me try to summarize our conversations from yesterday.
> 
> === Use Case ===
> Assume we have a Domain D which contains a large number of individual users.
> Each user in the domain creates a public / private key. This key pair is later
> used to establish authentication to services, some not from OpenStack.
> 
> === Challenge ===
> All the user specific projects belong to the D Domain. This means that any
> user with read permissions on the domain will be able to access the user
> specific secrets. As it seems likely that many users will be given domain read
> permissions, this violates least privilege by allowing a large number of users
> access to secret data that they don't need.
> 
> === Initial Proposal ===
> The original proposal was to scope secrets to a composite key of the project
> id and the user id from the user who created the secret. There is some concern
> from both Keystone and Barbican members that this approach violates the base
> assumption that, in OpenStack, the lowest level of authorization is a project.
> 
> === Open Question ===
> My current thinking is that since these keys are user specific and Keystone
> owns the user resource in OpenStack, it is starting to feel like this type of
> data should more properly be owned by the Keystone service rather than
> Barbican. Of course, Keystone could use Barbican for backend storage if
> desired.
> 
> 
> I'd really like to get some feedback from the Keystone folks on how they think
> about this one as, more and more, it's feeling like a problem that Barbican
> shouldn't solve. 
> 
> 
> Thanks,
> Jarret
> 
> 
> From: , Arvind 
> Reply-To: OpenStack List 
> Date: Thursday, May 15, 2014 at 8:21 AM
> To: OpenStack List 
> Cc: "Jones, Brant" , "Chan, Tim" ,
> "Thyne, Bob" , Morgan Fainberg 
> Subject: [openstack-dev] [keystone] [barbican] Protecting user specific
> secrets in Barbican
> 
>> Barbcan will be used as secret store (or Key Manager) in Open Stack
>> deployments. That means users can store any kind for secrets (ssh keys ,
>> access keys, password Š..) in Barbican these secrets are not shared secrets.
>>  
>> In below scenario it seems secrets are not well protected in Barbican
>>  
>> 1.  Barbican in integrated a OS based cloud deployment.
>> 
>> 2.  In particular domain there is one (or multiple) project.
>> 
>> 3.  Users are associated with the project through role (two coworker can
>> have same role e.g. creator) or a admin user have higher role.
>> 
>> 4.  Users have their secrets (ssh keys , access keys, password Š..) for
>> services (VMs per users, resources) saved in Barbican.
>> 
>>  
>>  
>> Problem
>>  
>> 1.  Users with the same role or Admin on project can see each other
>> secrets which are not a shared secrets.
>> 
>> 2.  Multiple projects (or project hierarchy) per user just to store
>> secrets is not going to help as it will lead to project exposition and
>> confusing. At the same time projects are not meant to go 1 to 1 with user.
>> 
>> 3.  Project hierarchy is also not a good solution as user on top of the
>> hierarchy (reseller admin) can inherits role and able to steal the secrets.
>> 
>>  
>>  
>> Note, Barbican is designed for secret storage and protection, we need better
>> management on secrets in Barbican. We also need better solution to address
>> this problem.
>>  
>>  
>> Keystone and Barbican (or interested party) team, can we have a meeting today
>> to brainstorm this issue and come up with better solution?
>>  
>>  
>> Thanks
>> Arvind  
>>  
>>  
>>  




smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] [barbican] Protecting user specific secrets in Barbican

[Jarret Raim]

So let me try to summarize our conversations from yesterday.

=== Use Case ===
Assume we have a Domain D which contains a large number of individual users.
Each user in the domain creates a public / private key. This key pair is
later used to establish authentication to services, some not from OpenStack.

=== Challenge ===
All the user specific projects belong to the D Domain. This means that any
user with read permissions on the domain will be able to access the user
specific secrets. As it seems likely that many users will be given domain
read permissions, this violates least privilege by allowing a large number
of users access to secret data that they don't need.

=== Initial Proposal ===
The original proposal was to scope secrets to a composite key of the project
id and the user id from the user who created the secret. There is some
concern from both Keystone and Barbican members that this approach violates
the base assumption that, in OpenStack, the lowest level of authorization is
a project.

=== Open Question ===
My current thinking is that since these keys are user specific and Keystone
owns the user resource in OpenStack, it is starting to feel like this type
of data should more properly be owned by the Keystone service rather than
Barbican. Of course, Keystone could use Barbican for backend storage if
desired.


I'd really like to get some feedback from the Keystone folks on how they
think about this one as, more and more, it's feeling like a problem that
Barbican shouldn't solve.


Thanks,
Jarret


From:  , Arvind 
Reply-To:  OpenStack List 
Date:  Thursday, May 15, 2014 at 8:21 AM
To:  OpenStack List 
Cc:  "Jones, Brant" , "Chan, Tim" ,
"Thyne, Bob" , Morgan Fainberg 
Subject:  [openstack-dev] [keystone] [barbican] Protecting user specific
secrets in Barbican

> Barbcan will be used as secret store (or Key Manager) in Open Stack
> deployments. That means users can store any kind for secrets (ssh keys ,
> access keys, password Š..) in Barbican these secrets are not shared secrets.
>  
> In below scenario it seems secrets are not well protected in Barbican
>  
> 1.  Barbican in integrated a OS based cloud deployment.
> 
> 2.  In particular domain there is one (or multiple) project.
> 
> 3.  Users are associated with the project through role (two coworker can
> have same role e.g. creator) or a admin user have higher role.
> 
> 4.  Users have their secrets (ssh keys , access keys, password Š..) for
> services (VMs per users, resources) saved in Barbican.
> 
>  
>  
> Problem
>  
> 1.  Users with the same role or Admin on project can see each other
> secrets which are not a shared secrets.
> 
> 2.  Multiple projects (or project hierarchy) per user just to store
> secrets is not going to help as it will lead to project exposition and
> confusing. At the same time projects are not meant to go 1 to 1 with user.
> 
> 3.  Project hierarchy is also not a good solution as user on top of the
> hierarchy (reseller admin) can inherits role and able to steal the secrets.
> 
>  
>  
> Note, Barbican is designed for secret storage and protection, we need better
> management on secrets in Barbican. We also need better solution to address
> this problem.
>  
>  
> Keystone and Barbican (or interested party) team, can we have a meeting today
> to brainstorm this issue and come up with better solution?
>  
>  
> Thanks
> Arvind  
>  
>  
>  




smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] HEEEELP please..How can use Openstack 's APIs in Javascript/Ajax??

[Jarret Raim]

Hachem,

Were you looking for a pre-existing javascript library? I'm not familiar
with one, but someone else might chime in. The OpenStack APIs are all ReST /
JSON and should be easily consumable from a client side.

You might want to look at / ask the Horizon project. They are the UI for
OpenStack and may be able to better answer you question. You can direct a
message to them by including [Horizon] in the subject of your email.



Thanks!


--
Jarret Raim 
@jarretraim


From:  Hachem Chraiti 
Reply-To:  OpenStack List 
Date:  Wednesday, May 7, 2014 at 9:42 AM
To:  OpenStack List ,
"openst...@ask.openstack.org" 
Subject:  [openstack-dev] HLP please..How can use Openstack 's APIs in
Javascript/Ajax??

HI can i use Openstack 's APIs in Javascript/Ajax?? Is there any solution
pleasE?




smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] SSL VPN Implemenatation

[Jarret Raim]

Zang mentioned that part of the issue is that the private key has to be
stored in the OpenVPN config file. If the config files are generated and
can be stored, then storing the whole config file in Barbican protects the
private key (and any other settings) without having to try to deliver the
key to the OpenVPN endpoint in some non-standard way.


Jarret

On 4/30/14, 6:08 PM, "Nachi Ueno"  wrote:

>> Jarret
>
>Thanks!
>Currently, the config will be generated on demand by the agent.
>What's merit storing entire config in the Barbican?
>
>> Kyle
>Thanks!
>
>2014-04-30 7:05 GMT-07:00 Kyle Mestery :
>> On Tue, Apr 29, 2014 at 6:11 PM, Nachi Ueno  wrote:
>>> Hi Clint
>>>
>>> Thank you for your suggestion. Your point get taken :)
>>>
 Kyle
>>> This is also a same discussion for LBaaS
>>> Can we discuss this in advanced service meeting?
>>>
>> Yes! I think we should definitely discuss this in the advanced
>> services meeting today. I've added it to the agenda [1].
>>
>> Thanks,
>> Kyle
>>
>> [1] 
>>https://wiki.openstack.org/wiki/Meetings/AdvancedServices#Agenda_for_next
>>_meeting
>>
 Zang
>>> Could you join the discussion?
>>>
>>>
>>>
>>> 2014-04-29 15:48 GMT-07:00 Clint Byrum :
 Excerpts from Nachi Ueno's message of 2014-04-29 10:58:53 -0700:
> Hi Kyle
>
> 2014-04-29 10:52 GMT-07:00 Kyle Mestery :
> > On Tue, Apr 29, 2014 at 12:42 PM, Nachi Ueno 
>wrote:
> >> Hi Zang
> >>
> >> Thank you for your contribution on this!
> >> The private key management is what I want to discuss in the
>summit.
> >>
> > Has the idea of using Barbican been discussed before? There are
>many
> > reasons why using Barbican for this may be better than developing
>key
> > management ourselves.
>
> No, however I'm +1 for using Barbican. Let's discuss this in
> certificate management topic in advanced service session.
>

 Just a suggestion: Don't defer that until the summit. Sounds like
you've
 already got some consensus, so you don't need the summit just to
rubber
 stamp it. I suggest discussing as much as you can right now on the
mailing
 list, and using the time at the summit to resolve any complicated
issues
 including any "a or b" things that need crowd-sourced idea making. You
 can also use the summit time to communicate your requirements to the
 Barbican developers.

 Point is: just because you'll have face time, doesn't mean you should
 use it for what can be done via the mailing list.

 ___
 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
>
>___
>OpenStack-dev mailing list
>OpenStack-dev@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] SSL VPN Implemenatation

[Jarret Raim]

As the PTL for Barbican, I¹m happy to discuss this more here or at the
Summit. 

Not sure if this is an option, but could you store the entire OpenVPN
config file in Barbican rather than just the key? Not sure if you are
generating those on demand or not, but we¹ve had several teams inside
Rackspace just storing entire config files rather than trying to separate
out individual keys or passwords.

Jarret




On 4/30/14, 12:11 AM, "Nachi Ueno"  wrote:

>Hi Clint
>
>Thank you for your suggestion. Your point get taken :)
>
>> Kyle
>This is also a same discussion for LBaaS
>Can we discuss this in advanced service meeting?
>
>> Zang
>Could you join the discussion?
>
>
>
>2014-04-29 15:48 GMT-07:00 Clint Byrum :
>> Excerpts from Nachi Ueno's message of 2014-04-29 10:58:53 -0700:
>>> Hi Kyle
>>>
>>> 2014-04-29 10:52 GMT-07:00 Kyle Mestery :
>>> > On Tue, Apr 29, 2014 at 12:42 PM, Nachi Ueno  wrote:
>>> >> Hi Zang
>>> >>
>>> >> Thank you for your contribution on this!
>>> >> The private key management is what I want to discuss in the summit.
>>> >>
>>> > Has the idea of using Barbican been discussed before? There are many
>>> > reasons why using Barbican for this may be better than developing key
>>> > management ourselves.
>>>
>>> No, however I'm +1 for using Barbican. Let's discuss this in
>>> certificate management topic in advanced service session.
>>>
>>
>> Just a suggestion: Don't defer that until the summit. Sounds like you've
>> already got some consensus, so you don't need the summit just to rubber
>> stamp it. I suggest discussing as much as you can right now on the
>>mailing
>> list, and using the time at the summit to resolve any complicated issues
>> including any "a or b" things that need crowd-sourced idea making. You
>> can also use the summit time to communicate your requirements to the
>> Barbican developers.
>>
>> Point is: just because you'll have face time, doesn't mean you should
>> use it for what can be done via the mailing list.


smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Barbican PTL Candidacy

[Jarret Raim]

I'd like to throw my name in for PTL for the Key Management Program which
includes the Barbican, python-barbicanclient and Kite projects.

I've been working on Barbican since the first line of code was committed
and was responsible for building the team and desire at Rackspace to start
the project. It is a confluence of ideas from my time as a security
consultant, internal security architect and OpenStack contributor. I
believe that Barbican is key to allowing other projects in OpenStack to
expose desired features in the encryption space while meeting requirements
from security or compliance conscious customers. Additionally, the team
that we build for Barbican (both inside and outside of Rackspace) tends to
draw security minded folks that contribute their time and expertise to the
community.

My goal for the Juno cycle is to move Barbican through the incubation
process while incorporating the Kite work done in Keystone and filling out
the next set of planned features. With the requirements for integration
being clarified now, I'm not sure we'll be ready for integration in the
Juno cycle, but we will certainly be tackling as many of those as possible.

In addition to the integration work, Barbican has several community and
feature goals:

Community:
* Continue to drive wider community adoption. We've had a great start with
folks from HP, Nebula, Red Hat and others, but we want to continue to
diversify the team.
* Adopt a new blueprint system using Gerrit similar to Nova
* Discuss the future of the oslo.crypto libraries with the Oslo team
* Continue to evangelize Barbican and OpenStack in various venues through
speaking and training engagements


Features:
* Asymmetric key generation and escrow support include support for
external CAs
* Land the Dogtag support patches from Red Hat
* Auditing and logging compliance requirements
* Land the preliminary work done for the Kite project





Thanks,
Jarret


smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Proposal to move from Freenode to OFTC

[Jarret Raim]

>#1) do we believe OFTC is fundamentally better equipped to resist a
>DDOS, or do we just believe they are a smaller target? The ongoing DDOS
>on meetup.com the past 2 weeks is a good indicator that being a smaller
>fish only helps for so long.

It seems like we would need a answer to this question. If the main reason
to switch is to avoid DDoS interruptions, the question would really boil
down to whether the OFTC is actually more resilient to DDoS or if they
just haven't had to deal with it.


Jarret


smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [barbican] Meeting Today

[Jarret Raim]

All,

Barbican will be having our weekly meeting in #openstack-meeting-alt in 30
minutes at 2:00pm Central, 2000 UTC.

On the list today is a quick discussion covering the status of the
Barbican incubation request. We may also discuss the asymmetric work going
on and possibly an update on Dogtag support.

Drop of by if you have questions, we should have time to add things to the
agenda.



Thanks,
Jarret


smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Barbican Incubation Review

[Jarret Raim]

I spun one up here

https://etherpad.openstack.org/p/GFoJ4LpK8A



Most of the questions are on our incubation wiki, but I answered each of
the issues from the page you linked.



Thanks,
--
Jarret Raim 
@jarretraim





On 2/4/14, 7:45 AM, "Thierry Carrez"  wrote:

>Jarret Raim wrote:
>> Barbican, the key management service for OpenStack, requested incubation
>> before the holidays. After the initial review, there were several issues
>> brought up by various individuals that needed to be resolved
>> pre-incubation. At this point, we have completed the work on those
>>tasks.
>> I'd like to request a final review before a vote on our incubation at
>>the
>> next TC meeting, which should be on 2/4.
>> 
>> The list of tasks and their status is documented as part of our
>>incubation
>> request, which is on the openstack wiki:
>> https://wiki.openstack.org/wiki/Barbican/Incubation
>
>In preparation for the meeting later today, you could also prepare an
>etherpad describing where you currently stand compared to incubation
>requirements as described in the governance repo[1]. That will help
>speed up your review.
>
>[1]
>http://git.openstack.org/cgit/openstack/governance/tree/reference/incubati
>on-integration-requirements
>
>-- 
>Thierry Carrez (ttx)
>
>___
>OpenStack-dev mailing list
>OpenStack-dev@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Speaking at PyCON US 2014 about OpenStack?

[Jarret Raim]

Paul Kehrer and I are talking about the state of crypto in Python. The
talk isn't specifically about OpenStack, but we will be talking about
various OpenStack related issues including the Barbican service.


Thanks,
Jarret




On 1/30/14, 11:05 AM, "Anita Kuno"  wrote:

>On 01/30/2014 09:51 AM, Doug Hellmann wrote:
>> On Thu, Jan 30, 2014 at 11:14 AM, Anita Kuno 
>>wrote:
>> 
>>> On 01/30/2014 08:42 AM, Stefano Maffulli wrote:
 If you're going to talk about anything related to OpenStack at PyCON
 US/Canada this year, please let me know. We're collecting the list of
 talks related to the project.

 Cheers,
 stef

>>> Would it be possible to start an etherpad for this? I am considering
>>> offering a workshop or lab of some sort (if I haven't missed the
>>> deadline for that) but don't want to be stepping on toes if someone
>>>else
>>> is already covering that material.
>>>
>> 
>> The deadline for formal conference talks and tutorials has passed [1],
>>but
>> you could still schedule an open space room on site [2].
>> 
>> [1] https://us.pycon.org/2014/speaking/cfp/
>> [2] https://us.pycon.org/2014/community/openspaces/
>> 
>> Doug
>Thanks Doug, I had thought I had seen something fly past me that
>mentioned something about offer a workshop or something but it appears
>that was over in September - too late.
>
>So ignore my request and thanks anyway,
>Anita.
>> 
>> 
>> 
>>>
>>> Thanks,
>>> Anita.
>>>
>>> ___
>>> 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


smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Barbican Incubation Review

[Jarret Raim]

I'd be happy to remove it for now. As I said, this is a staging location to
allow us to test that our docs generation process is working, it is not
documented anywhere and no one is using it. I just wanted to show that the
team is working on moving things over.

Jarret

From:  Anne Gentle 
Reply-To:  OpenStack List 
Date:  Wednesday, January 29, 2014 at 4:54 PM
To:  OpenStack List 
Cc:  "barbi...@lists.rackspace.com" 
Subject:  Re: [openstack-dev] Barbican Incubation Review




On Wed, Jan 29, 2014 at 2:42 PM, Jarret Raim 
wrote:
> 
> All,
> 
> Barbican, the key management service for OpenStack, requested incubation
> before the holidays. After the initial review, there were several issues
> brought up by various individuals that needed to be resolved
> pre-incubation. At this point, we have completed the work on those tasks.
> I'd like to request a final review before a vote on our incubation at the
> next TC meeting, which should be on 2/4.
> 
> The list of tasks and their status is documented as part of our incubation
> request, which is on the openstack wiki:
> https://wiki.openstack.org/wiki/Barbican/Incubation
> 
> 
> The only outstanding PR on the list is our devstack integration. I'd love
> it if we could get some eyes on that patch. Things seem to be working for
> us in our testing, but it'd be great to get some feedback from -infra to
> make sure we aren¹t going to cause any headaches for the gate. The review
> is here:
> https://review.openstack.org/#/c/69962
> 
> 
> During our initial request, there was a conversation about our being a
> mostly Rackspace driven effort. While it was decided that diversifying the
> team isn't a requirement for incubation, it is for integration and we've
> made some headway on that effort. At this point, we have external
> contributors from eVault, HP and RedHat that have submitted code and / or
> blueprints for the system. There are other folks that have expressed
> interest in contributing, so I'm hopeful that our team will continue to
> diversify over the course of our incubation period.
> 
> Our general page is here:
> https://wiki.openstack.org/wiki/Barbican
> 
> Our GitHub documentation:
> https://github.com/cloudkeep/barbican
> https://github.com/cloudkeep/barbican/wiki
> 
> We are currently working on moving this documentation to the OpenStack
> standard docbook format. We have a ways to go on this front, but the
> staging area for that work can be found here:
> http://docs.cloudkeep.io/barbican-devguide/content/preface.html
> 
> 
Hi Jarret -
Please don't use the OpenStack branding on your output prior to permission
through this process.
Thanks,
Anne
 
> The team hangs out in the #openstack-barbican channel on freenode. If you
> want to talk, stop on by.
> 
> 
> Thanks,
> 
> Jarret Raim
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 





smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Barbican Incubation Review

[Jarret Raim]

On 1/29/14, 4:21 PM, "Justin Santa Barbara"  wrote:

>* the API for asymmetric keys (i.e. keys with a public and private
>part) has not yet been fleshed out

That's correct. We are working with folks from HP and others on the
blueprints to implement asymmetric support. Our hope is to have it done
for Icehouse, but it is pretty late in the game, so it might wait until
Juno.

>* there does not appear to be support for key rotation

We currently don't allow keys to be modified. We have talked about key
rotation and there are one interesting ideas we have about how that might
work. I'd love to work on it at some point, but I did want to get some
feedback form the community before we implemented it as the different
implementations have trade-offs.

>* I don't see metadata or tags or some other way for API consumers to
>attach extra information they might need

Our schemas do allow for meta-data and some addition work on the
Containers concept will allow for more flexibility in that arena.

>* "cypher_type" is spelled in the less common way

I certainly don't mind changing that if there is consensus :)


>I'm presuming that this is our last opportunity for API review - if
>this isn't the right occasion to bring this up, ignore me!

I wouldn't agree here. The barbican API will be evolving over time as we
add new functionality. We will, of course, have to deal with backwards
compatibility and version as we do so. We're also looking at adopting the
model that Keystone uses for API blueprints where the API changes are
separate blueprints that are reviewed by a larger group than the
implementations.


Thanks,
Jarret



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


smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Barbican] New developer is coming

[Jarret Raim]

Thanks Adam. 

The guys working on this are hdegikli and reaperhulk. The easiest way to
fine them is in #openstack-barbican. I'll cc reaperhulk on this so you have
his email. I don't think I have hdegikli's email.


Thanks,
Jarret


From:  Александра Безбородова 
Reply-To:  OpenStack List 
Date:  Tuesday, January 28, 2014 at 9:41 PM
To:  OpenStack List 
Subject:  Re: [openstack-dev] [Barbican] New developer is coming

Thx, Adam!


2014-01-29 Adam Young 
> On 01/28/2014 09:55 PM, Александра Безбородова wrote:
>> Hi all, 
>> I want to participate in Barbican project. I'm interested in this bp
>> https://blueprints.launchpad.net/barbican/+spec/support-rsa-key-store-generat
>> ion
>> Who can answer some questions about it?
>> 
>>  
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/l
>> istinfo/openstack-dev
> Get on Freenode and ask in #openstack-barbican
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 





smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] [Barbican] nova-cert information

[Jarret Raim]

We are currently hammering out the blueprints for asymmetric key support
(both for escrow and generation). Happy to talk more about your use case if
you are interested. We can do it over email or you can hop into
#openstack-barbican on Freenode and talk to the team there.


Thanks,
Jarret

From:  Vishvananda Ishaya 
Reply-To:  OpenStack List 
Date:  Wednesday, January 29, 2014 at 12:12 AM
To:  OpenStack List 
Subject:  Re: [openstack-dev] [Nova] [Barbican] nova-cert information

I would not want to use nova-cert for something like this. It was a minimum
viable option for supporting the ec2 upload bundle use case which requires
certs to work. We also managed to get it working for our hacky vpn solution
long ago, but it is definitely not a best practices case. Perhaps certs
could be added to barbican (if it doesn¹t support them already?)

https://github.com/stackforge/barbican

Vish

On Jan 23, 2014, at 5:00 PM, Miller, Mark M (EB SW Cloud - R&D - Corvallis)
 wrote:

> Hello,
>  
> I am trying to locate information about what services the nova-cert service
> provides and whether or not it can be used to distribute certificates in a
> cloud. After several hours of web surfing I have found very little
> information. I am writing in hopes that someone can point me to a tutorial
> that describes what this service can and cannot do.
>  
> Thank you in advance,
>  
> Mark
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev





smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Barbican Incubation Review

[Jarret Raim]

All,

Barbican, the key management service for OpenStack, requested incubation
before the holidays. After the initial review, there were several issues
brought up by various individuals that needed to be resolved
pre-incubation. At this point, we have completed the work on those tasks.
I'd like to request a final review before a vote on our incubation at the
next TC meeting, which should be on 2/4.

The list of tasks and their status is documented as part of our incubation
request, which is on the openstack wiki:
https://wiki.openstack.org/wiki/Barbican/Incubation


The only outstanding PR on the list is our devstack integration. I'd love
it if we could get some eyes on that patch. Things seem to be working for
us in our testing, but it'd be great to get some feedback from -infra to
make sure we aren¹t going to cause any headaches for the gate. The review
is here: 
https://review.openstack.org/#/c/69962


During our initial request, there was a conversation about our being a
mostly Rackspace driven effort. While it was decided that diversifying the
team isn't a requirement for incubation, it is for integration and we've
made some headway on that effort. At this point, we have external
contributors from eVault, HP and RedHat that have submitted code and / or
blueprints for the system. There are other folks that have expressed
interest in contributing, so I'm hopeful that our team will continue to
diversify over the course of our incubation period.

Our general page is here:
https://wiki.openstack.org/wiki/Barbican

Our GitHub documentation:
https://github.com/cloudkeep/barbican
https://github.com/cloudkeep/barbican/wiki

We are currently working on moving this documentation to the OpenStack
standard docbook format. We have a ways to go on this front, but the
staging area for that work can be found here:
http://docs.cloudkeep.io/barbican-devguide/content/preface.html


The team hangs out in the #openstack-barbican channel on freenode. If you
want to talk, stop on by.


Thanks,

Jarret Raim


smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Incubation Request for Barbican

[Jarret Raim]

> -Original Message-
> From: Steven Dake [mailto:sd...@redhat.com]
> In this particular case, I believe Barbican is not ready for incubation
because
> of their dependence on celery, but ultimately I don't make the decision :)

We've landed the PR that removes celery and replaces it with oslo.messaging.


As Thierry said, once we are finished with the other couple of requests from
the TC and we'll re-apply after the holidays.

Other than that, I agree with everything you said :)



Jarret


smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Diversity as a requirement for incubation

[Jarret Raim]

> It is a difficult thing to measure, and I don't think the intent is to set
a hard % 
> for contributions. I think the numbers for Barbican were just illustrating
the 
> fact that the concrete contributions are very coming very heavily from one

> source. That's only one data point, though, and as you point out there are
a 
> lot of other way to contribute.

Agreed. I don't think the conclusion (e.g. Barbican is mostly a Rackspace
driven endeavor at the moment) was incorrect, just that if we are going to
codify the social requirement, we need to have a larger definition than just
code commit %.

> For example, another criteria could be whether the project has core
reviewers 
> from multiple companies, where each is doing some significant proportion
of reviews.

A good option. Still leaves the chicken and the egg problem of how to get
other ATCs interested in reviewing patches for a product they don't work on
that may not be incubated.

 
> I think we've been lucky on that count. I'm not sure how I feel about the
requirement 
> for entering incubation, yet, but I do feel strongly that we need to have
diverse contributors 
> when a project graduates from incubation.

I don't know about lucky or not. If the project has been working in the mode
of not requiring it for years and there have been no problems, why would we
assume they would somehow start? Shouldn't we optimize for the data we have
rather than a guess of future pain? On the technical side, most of the
requirements should be driven from things that have caused pain to OpenStack
projects (rather than sacred cows / opinions / guesses of future pain). They
should be discussed, agreed upon and documented before projects get into the
incubation cycle so that everyone knows the goals going in. The social
requirements seem like they should meet the same standard.

To me, we just need to codify the risk of a project failing to integrate
after incubation. What would be the downside if we incubate a product that
subsequently needs to be removed (for technical or social reasons)? How much
pain does this cause? Is it worth turning away or slowing projects that
solve needs for OpenStack to avoid this pain?

We already have data that says there is a low chance of this happening, so
how much do we want to optimize to reduce that risk before we just accept
that it is there and deal with it when it happens?

There seems to be broad support for the 'required for graduation' bar, which
I'm fine with. It seems like we just need to nail down whether it is
required pre-incubation or not. 


Jarret




smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Diversity as a requirement for incubation

[Jarret Raim]

> -Original Message-
> From: Sylvain Bauza [mailto:sylvain.ba...@bull.net]
> Sent: Wednesday, December 18, 2013 5:04 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] Diversity as a requirement for incubation
> 
> Le 18/12/2013 11:40, Thierry Carrez a écrit :
> > I guess there are 3 options:
> >
> > 1. Require diversity for incubation, but find ways to bless or
> > recommend projects pre-incubation so that this diversity can actually
> > be achieved
> >
> > 2. Do not require diversity for incubation, but require it for
> > graduation, and remove projects from incubation if they fail to
> > attract a diverse community
> >
> > 3. Do not require diversity at incubation time, but at least judge the
> > interest of other companies: are they signed up to join in the future ?
> > Be ready to drop the project from incubation if that was a fake
> > support and the project fails to attract a diverse community
> >
> > Personally I'm leaning towards (3) at the moment. Thoughts ?
> 
> I would vote for (1). FWIW, incubated projects are robust enough to fail
from
> a resource perspective.
> That definitely goes to what an incubated project is : to me, incubated
> projects *will* be integrated, but they currently aren't due to some
> *technical* (code compliancy, unittesting, frameworks, integration with
> other projects) concerns.

I would go the entirely opposite direction. It is difficult to get community
support for unrecognized projects, especially when that support is usually
in the form of FTEs from interested companies. Without some assurance that
the project will make it into OpenStack, it is significantly more difficult
to get companies to assign resources. Coming up with another status doesn't
seem to solve that problem unless that status is 'this will be in OpenStack
soon, start collaborating' which, to me, is what incubation is designed to
do. If the new status requires no investment from OpenStack, then it doesn't
signal any strong commitment, making it less clear that other vendors should
support the effort.

I would say that fixing some technical issues pre-incubation seems fine, but
expecting every project to have a diverse (as in multi-vendor) team before
the project has achieved any type of status is difficult. Also, any general
technical requirements should be documented beforehand. For Barbican, there
seems to be a lot of goalpost moving in that people just say what they want
and there is very little way for us to know what those requirements will be.


Additionally, measuring diversity of a project is also difficult. The
current measure being used is commit percentage, which is terrible. If a
project bakes for a while with a core set of developers, it will take a long
time for new contributors to make a dent in the percentages. It also
incentives bad behavior, e.g. wrapping up lots of small commits into one big
one, etc. We need more inclusive measures, maybe including intent to deploy,
etc. 

Barbican has been open since its inception. It has never been closed or
limited in any way. However, we didn't really start getting interest until
we reached our MVP. We have interest now, but even though people have
started contributing, it will take a while to chip away at the commit
percentages. 

For me, I would be fine with #2 or #3 (they seem very similar), but I don't
think #1 is realistic. Keep in mind that many of the current OpenStack
programs & projects were incubated without diverse communities. This doesn't
seem to have caused outsized headaches.


> If we assess that incubated projects could not part of Openstack one day
or
> so, that won't help community adoption and/or resources dedication.

If something gets kicked out of incubation, it is explicitly because it
didn't garner any additional community support. By being in incubation, the
project becomes the owner of a particular set of features. If no one joins,
it's either because the no one is interested in that feature set, the
project's community is not receptive or the project already meets the needs
of the user and they don't need to contribute devs. I see this as happening
very rarely, but only if we get better measures for diversity.


Jarret


smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Incubation Request for Barbican

[Jarret Raim]

On 12/13/13, 7:56 AM, "Russell Bryant"  wrote:


>1) Are each of the items you mention big enough to have a sustainable
>team that can exist as its own program?

The answer here for Barbican and Keystone is yes.

>2) Would there be a benefit of *changing* the scope and mission of the
>Identity program to accomodate a larger problem space?  "Security"
>sounds too broad ... but I'm sure you see what I'm getting at.

Dolph and I have talked about this a bit. Right now, if we combined them,
it feels like we would have meetings where the first half would be about
Keystone and the second about Barbican. Same for design sessions. The
systems and the concerns they address are entirely separate. Currently the
teams are also entirely separate.

While I think we can encourage both teams to have a close relationship
(Adam Young and I had a conversion about that recently), there is no
benefit to combining the teams now other than to reduce the number of
programs. As the combination doesn¹t help either project, it seems like
Barbican having its own program is the best option.

>When we're talking about authentication, authorization, identity
>management, key management, key distribution ... these things really
>*do* seem related enough that it would be *really* nice if a group was
>looking at all of them and how they fit into the bigger OpenStack
>picture.  I really don't want to see silos for each of these things.

I don¹t agree here. Key management and distribution can be used to solve
problems in the identity space. They can also be used to solve problems in
other spaces in openstack. Barbican uses keystone to provide auth / auth
to keys, much like Nova uses keystone to provide auth / auth to servers.
Additionally, Barbican will deal with other parts of the encryption space
(e.g. SSL) that have very little to do with identity.

>So, would OpenStack benefit from a tighter relationship between these
>projects?  I think this may be the case, personally.

I think there would be benefit to individuals working together from the
two projects where it makes sense - especially where we have knowledge
overlaps. I don¹t agree that including Barbican in the Identity program is
the right way to do that.

>Could this tighter relationship happen between separate programs?  It
>could, but I think a single program better expresses the intent if
>that's really what is best.

Barbican¹s intent is to simplify key management to enable consuming
systems and users to offer or use encryption in their services. This is a
fundementally different mission than Keystone has.



Jarret


smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Incubation Request for Barbican

[Jarret Raim]

On 12/13/13, 4:50 AM, "Thierry Carrez"  wrote:


>If you remove Jenkins and attach Paul Kehrer, jqxin2006 (Michael Xin),
>Arash Ghoreyshi, Chad Lung and Steven Gonzales to Rackspace, then the
>picture is:
>
>67% of commits come from a single person (John Wood)
>96% of commits come from a single company (Rackspace)
>
>I think that's a bit brittle: if John Wood or Rackspace were to decide
>to place their bets elsewhere, the project would probably die instantly.
>I would feel more comfortable if a single individual didn't author more
>than 50% of the changes, and a single company didn't sponsor more than
>80% of the changes.


I think these numbers somewhat miss the point. It is true that Rackspace
is the primary sponsor of Barbican and that John Wood is the developer
that has been on the project the longest. However, % of commits is not the
only measure of contributions to the project. That number doesn¹t include
the work on our chef-automation scripts or design work to figure out the
HSM interfaces or work on the testing suite or writing our documentation
or the million other tasks for the project.

Rackspace is committed to this project. If John Wood leaves, we¹ll hire
additional developers to replace him. There is no risk of the project
lacking resources because a single person decides to work on something
else. 

We¹ve seen other folks from HP, RedHat, Nebula, etc. say that they are
interested in contributing and we are getting outside contributions today.
That will only continue, but I think the risk of the project somehow
collapsing is being overstated.

There are problems that aren¹t necessarily the sexiest things to work on,
but need to be done. It may be hard to get a large number of people
interested in such a project in a short period of time. I think it would
be a mistake to reject projects that solve important problems just because
the team is a bit one sided at the time.





Jarret


smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [barbican] Meeting Today at 20:00 UTC (2 Central)

[Jarret Raim]

The barbican meeting today will cover our progress on the incubation
issues brought up by the TC, test planning and any other issues.


If you are interested in barbican and have questions, stop on by
#openstack-meeting-alt in 20 minutes.




Thanks,

--
Jarret Raim 
@jarretraim




smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Incubation Request for Barbican

[Jarret Raim]

> I'd like to look at keeping things simple when they can be simple. I
>need to understand why there¹s
> already a key distribution service under keystone?
>
> 
>https://review.openstack.org/#/c/40692/18/openstack-identity-api/v3/src/ma
>rkdown/identity-api-v3-os-kds-ext.md

I¹ve said before that I think the KDS more properly belongs in Barbican
rather than Keystone. There is a thread on this list detailing other
people¹s thoughts on the issue. I think the issue boiled down to two main
concerns. First, some are concerned / resistant about having to install
another service. Second, Barbican is going through our incubation process
right now. Some felt that they didn¹t wan to wait and that Keystone was
the shorter path.

> There could be two ways of looking at this - is Identity changing their
>scope? Or is an incubating
> project trying to take work away from an existing program? Not sure. I
>mostly just want to know who is
> best served by a new code base getting incubated under our defined
>umbrella.

Dolph can better answer the question about scope, but I think the KDS
going into Keystone is a matter of expediency rather than best fit.  As
I¹ve mentioned before, Keystone will use Barbican to satisfy some of their
requirements, but key management is a fundamentally separate process from
identity management.

> I agree that Barbican solves different problems than identity, and we
>need to figure out the motivations
> for the seeming pressing need to differentiate from
>keystone-the-project. There's autonomy, gathering
> your own team, and probably other reasons. Can you expand on your need
>for pursuing this incubation route?

I sent out a mail to this list of the types of things that Barbican will
tackle that have nothing to do with identity. These processes are
fundamentally different than those in Keystone and the Keystone
functionality is completely separate from anything that Barbican will do.

There have been several folks asking this questions and I¹m honestly
confused where the desire to push the two projects together is coming
from. Can someone be more specific about why they think these two projects
overlap? Is it solely because they both have to do with security? Or is
there something else?

> I do realize we are clarifying our incubation route, so partially we
>need to explore the "incubation under an existing²
> possibility and pros and cons. I'm doing something unofficial with the
>training group, for example. There are certainly
> pros and cons there. But I don't want to muddy the waters with that
>discussion, I want to hear from Barbican about your
> explorations of collaborating with Keystone and your motivations for
>wanting a separate application.

This certainly sounds like a good idea, but I don¹t think it applies to
the Barbican / Keystone projects.



Thanks,
Jarret


smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Barbican] IRC Meeting Today at 2 Central (2000 UTC)

[Jarret Raim]

Barbican is having our official IRC meeting in #openstack-meeting-alt today
at 2 central or 2000 UTC.

The main topic of conversation will be the tasks / comments that came up
from our incubation request. We welcome anyone with additional questions or
comments to come join us.



Thanks,

Jarret Raim   |Security Intrapreneur
-
5000 Walzem RoadOffice: 210.312.3121
San Antonio, TX 78218   Cellular: 210.437.1217
-
rackspace hosting   |   experience fanatical support




smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Incubation Request for Barbican

[Jarret Raim]

> While I am all for adding a new program, I think we should only add one
>if we 
> rule out all existing programs as a home. With that in mind why not add
>this 
> to the  keystone program? Perhaps that may require a tweak to keystones
>mission 
> statement, but that is doable. I saw a partial answer to this somewhere
>but not a full one.

>From our point of view, Barbican can certainly help solve some problems
related to identity like SSH key management and client certs. However,
there is a wide array of functionality that Barbican will handle that is
not related to identity.


Some examples, there is some additional detail in our application if you
want to dig deeper [1].


* Symmetric key management - These keys are used for encryption of data at
rest in various places including Swift, Nova, Cinder, etc. Keys are
resources that roll up to a project, much like servers or load balancers,
but they have no direct relationship to an identity.

* SSL / TLS certificates - The management of certificate authorities and
the issuance of keys for SSL / TLS. Again, these are resources rather than
anything attached to identity.

* SSH Key Management - These could certainly be managed through keystone
if we think that¹s the right way to go about it, but from Barbican¹s point
of view, these are just another type of a key to be generated and tracked
that roll up to an identity.


* Client certificates - These are most likely tied to an identity, but
again, just managed as resources from a Barbican point of view.

* Raw Secret Storage - This functionality is usually used by applications
residing on an Cloud. An app can use Barbican to store secrets such as
sensitive configuration files, encryption keys and the like. This data
belongs to the application rather than any particular user in Keystone.
For example, some Rackspace customers don¹t allow their application dev /
maintenance teams direct access to the Rackspace APIs.

* Boot Verification - This functionality is used as part of the trusted
boot functionality for transparent disk encryption on Nova.

* Randomness Source - Barbican manages HSMs which allow us to offer a
source of true randomness.



In short (ha), I would encourage everyone to think of keys / certificates
as resources managed by an API in much the same way we think of VMs being
managed by the Nova API. A consumer of Barbican (either as an OpenStack
service or a consumer of an OpenStack cloud) will have an API to create
and manage various types of secrets that are owned by their project.

Keystone plays a critical role for us (as it does with every service) in
authenticating the user to a particular project and storing the roles that
the user has for that project. Barbican then enforces these restrictions.
However, keys / secrets are fundamentally divorced from identities in much
the same way that databases in Trove are, they are owned by a project, not
a particular user.

Hopefully our thought process makes some sense, let me know if I can
provide more detail.



Jarret





[1] https://wiki.openstack.org/wiki/Barbican/Incubation


smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-tc] Incubation Request for Barbican

[Jarret Raim]

>> 
>> I think this conversation has gotten away from our incubation request
>>and
>> into an argument about what makes a good library and when and how
>>projects
>> should choose between oslo and other options. I¹m happy to have the
>>second
>> one in another thread, but that seems like a longer conversation that is
>> separate from our request.
>
>It's absolutely about your incubation request.  Part of this process is
>looking at the technical fit with the rest of OpenStack, and this is
>well within the scope of that discussion.

Oh understood, I’m just saying that the ask was to move away from Celery
to oslo.messaging. We’ve agreed to work on that and I don’t think there is
a problem in getting that done for Icehouse.

It is the larger discussion about whether oslo.messaging is really the
best approach that seems off topic. We’re going to use it, so the argument
is moot for now. If we want to take up that discussion, we can certainly
do that, but it more like a conversation that happens within the oslo
group rather than part of Barbican's request.

>I need to make another pass over the added info and go deeper into the
>technical bits, so I suspect there will be more feedback still.  It's
>only been a day.  :-)

Great. Always happy to have another set of eyes on the code.

>Also, note that most of the things brought up so far are based on the
>proposed requirements for becoming incubated, not for things to be
>worked on during incubation.  Unless the requirements change, so far it
>looks like this request should be deferred a bit longer.

We are working on the issues that have been brought up so far. Today, we
submitted a PR to add in pbr and the global requirements [1]. Once that
has been reviewed, we'll land it after the Icehouse-1 release. Note that
celery is still in the list until we complete the oslo.messengaging work.


Jarret




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


smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-tc] Incubation Request for Barbican

[Jarret Raim]

> The API and developer documentation is at
>http://docs.openstack.org/developer/oslo.messaging/

This is great, thanks for the link. Would there be any objections to
adding this to the github repo and the openstack wiki pages? I spent a
bunch of time looking and wasn¹t able to turn this up.


Additionally, where is this documentation generated from? I looked at the
doc/ dir in the repo [1] and most of the files in there were empty.


[1] https://github.com/openstack/oslo.messaging/tree/master/doc/source




Jarret


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

Re: [openstack-dev] [openstack-tc] Incubation Request for Barbican

[Jarret Raim]

>I think there's something else you should take under consideration.
>Oslo messaging is not just an OpenStack library. It's the RPC library
>that all projects are relying on and one of the strong goals we have
>in OpenStack is to reduce code and efforts duplications. We'd love to
>have more people testing and contributing to oslo.messaging in order
>to make it as battle tested as celery is.
>
>Please, don't get me wrong. I don't mean to say you didn't considered
>it, I just want to add another reason why we should always try to
>re-use the libraries that other projects are using - unless there's a
>strong technical reason ;).

As I¹ve said, we are willing to look at the library for Icehouse. As lots
of projects have implemented it, I hope that the switchover will be
reasonably easy. 

I think this conversation has gotten away from our incubation request and
into an argument about what makes a good library and when and how projects
should choose between oslo and other options. I¹m happy to have the second
one in another thread, but that seems like a longer conversation that is
separate from our request.

It seems like the comments are slowing down now. Does everyone feel our
list (https://wiki.openstack.org/wiki/Barbican/Incubation) accurately
captures the comments that have been brought up?

I filled out the Scope section of our request and I think we¹ve cleared up
the PTL election issue. Is there anything else I missed or have we covered
most of the issues?



Jarret


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

Re: [openstack-dev] Incubation Request for Barbican

[Jarret Raim]

>With the introduction of programs (think: official teams), all
>incubated/integrated projects must belong to an official program... So
>when a project applies for incubation but is not part of an official
>program yet, it de-facto also applies to be considered a program.

Ahh, understood. So I guess we'd be asking for a new program then.

>I'm not 100% sure we'll keep that "election" requirement. I think the
>program application should have an initial PTL named on it. The way
>that's determined is up to the team (natural candidate, election...).

It sounds like if we have a PTL election as part of the normal Icehouse
schedule, we should be covered here?

>No, since the team produces code the ATC designation method is pretty
>well established. This rule cares for programs which have weirder
>deliverables.

Easy enough, thanks for the clarification.



Jarret


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

Re: [openstack-dev] [openstack-tc] Incubation Request for Barbican

[Jarret Raim]

> I've been anxious to try out Barbican, but haven't had quite enough time
to
> try it yet. But finding out it won't work with Qpid makes it unworkable
for us
> at the moment. I think a large swath of the OpenStack community won't be
> able to use it in this form too.

As mentioned in the other thread, Barbican will be looking at oslo messaging
for Icehouse.

In the meantime, you can configure celery to use a pass-through (e.g. no
queue needed). This is the configuration we use for dev / testing. The
documentation for that can be found in the celery docs here:
http://docs.celeryproject.org/en/latest/userguide/


Jarret


smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-tc] Incubation Request for Barbican

[Jarret Raim]

> There are two big parts to this, I think.  One is techincal - a significant 
> portion
> of OpenStack deployments will not work with this because Celery does not
> work with their deployed messaging architecture.
>  See another reply in this thread for an example of someone that sees the
> inability to use Qpid as a roadblock for an example.  This is solvable, but 
> not
> quickly.
>
> The other is somewhat technical, but also a community issue.  Monty
> articulated this well in another reply.  Barbican has made a conflicting 
> library
> choice with what every other project using messaging is using.
> With the number of projects we have, it is in our best interest to strive 
> for
> consistency where we can.  Differences should not be arbitrary.  The
> differences should only be where an exception is well justified.  I don't 
> see
> that as being the case here.  Should everyone using oslo.messaging (or its
> predecessor rpc in oslo-incubator) be using Celery?  Maybe.  I don't know,
> but that's the question at hand.  Ideally this would have come up with a 
> more
> broad audience sooner.  If it did, I'm sorry I missed it.

I understand the concern here and I'm happy to have Barbican look at using 
oslo.messaging during the Icehouse cycle.

I am a bit surprised at the somewhat strong reactions to our choice. When we 
created Barbican, we looked at the messaging frameworks out there for use. At 
the time, oslo.messaging was not packaged, not documented, not tested, had no 
track record and an unknown level of community support.

Celery is a battle-tested library that is widely deployed with a good track 
record, strong community and decent documentation. We made our choice based on 
those factors, just as the same as we would for any library inclusion.

As celery has met our needs up to this point, we saw no reason to revisit the 
decision until now. In that time oslo.messaging  has moved to a separate repo. 
It still has little to no documentation, but the packaging and maintenance 
issues seem to be on the way to being sorted.

So in short, in celery we get a reliable library with good docs that is battle 
tested, but is limited to the transports supported by Kombu. Both celery and 
Kombu are extendable and have many backends including AMQP, Redis, Beanstalk, 
Amazon SQS, CouchDB, MongoDB, ZeroMQ, ZooKeeper, SoftLayer MQ and Pyro.

Oslo.messaging seems to have good support in OpenStack, but still lacks 
documentation and packaging (though some of that is being sorted out now). It 
offers support for qpid which celery seems to lack. It also offers a common 
place for message signing and some other nice to have features for OpenStack.

Based on the commonality in OpenStack (and the lack of anyone else using 
Celery), I think looking to move to oslo.messaging is a good goal. This will 
take some time, but I think doing it by Icehouse seems reasonable. I think 
that is what you and Monty are asking for?

I have added the task to our list on 
https://wiki.openstack.org/wiki/Barbican/Incubation.


Thanks again for all the eyeballs our on application.


Jarret



smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Incubation Request for Barbican

[Jarret Raim]

>>> Uses tox, but not pbr or global requirements
>> 
>> I added a ŒTasks¹ section for stuff we need to do from this review and
>> I¹ve added these tasks. [4]
>> 
>> [4] https://wiki.openstack.org/wiki/Barbican/Incubation
>
>Awesome. Also, if you don't mind - we should add "testr" to that list.
>We're looking at some things in infra that will need the subunit
>processing.

Added that to our list.



Jarret

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

Re: [openstack-dev] [openstack-tc] Incubation Request for Barbican

[Jarret Raim]

>>>  * Process
>>>  ** Project must be hosted under stackforge (and therefore use git as
>>>its VCS)
>> 
>> I see that barbican is now on stackforge,  but python-barbicanclient is
>> still on github.  Is that being moved soon?
>> 
>>>  ** Project must obey OpenStack coordinated project interface (such as
>>>tox,
>>> pbr, global-requirements...)
>> 
>> Uses tox, but not pbr or global requirements
>
>It's also pretty easy for a stackforge project to opt-in to the global
>requirements sync job now too.

Are there some docs on how to do this somewhere? I added a task for us to
complete the work as part of the incubation request here:
https://wiki.openstack.org/wiki/Barbican/Incubation


>>>  ** Project should use oslo libraries or oslo-incubator where
>>>appropriate
>> 
>> The list looks reasonable right now.  Barbican should put migrating to
>> oslo.messaging on the Icehouse roadmap though.
>
>*snip*
>
>> 
>> 
>>http://git.openstack.org/cgit/stackforge/barbican/tree/tools/pip-requires
>> 
>> It looks like the only item here not in the global requirements is
>> Celery, which is licensed under a 3-clause BSD license.
>
>I'd like to address the use of Celery.
>
>WTF
>
>Barbican has been around for 9 months, which means that it does not
>predate the work that has become oslo.messaging. It doesn't even try. It
>uses a completely different thing.
>
>The use of celery needs to be replaced with oslo. Full stop. I do not
>believe it makes any sense to spend further time considering a project
>that's divergent on such a core piece. Which is a shame - because I
>think that Barbican is important and fills an important need and I want
>it to be in. BUT - We don't get to end-run around OpenStack project
>choices by making a new project on the side and then submitting it for
>incubation. It's going to be a pile of suck to fix this I'm sure, and
>I'm sure that it's going to delay getting actually important stuff done
>- but we deal with too much crazy as it is to pull in a non-oslo
>messaging and event substrata.


Is the challenge here that celery has some weird license requirements? Or
that it is a new library?

When we started the Barbican project in February of this year,
oslo.messaging did not exist. If I remember correctly, at the time we were
doing architecture set up, the messaging piece was not available as a
standalone library, was not available on PyPi and had no documentation.

It looks like the project was moved to its own repo in April. However, I
can¹t seem to find the docs anywhere? The only thing I see is a design doc
here [1]. Are there plans for it to be packaged and put into Pypi?

We are probably overdue to look at oslo.messaging again, but I don¹t think
it should be a blocker for our incubation. I'm happy to take a look to see
what we can do during the Icehouse release cycle. Would that be
sufficient? 


[1] https://wiki.openstack.org/wiki/Oslo/Messaging




Jarret


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

Re: [openstack-dev] Incubation Request for Barbican

[Jarret Raim]

>
>The TC is currently working on formalizing requirements for new programs
>and projects [3].  I figured I would give them a try against this
>application.
>
>First, I'm assuming that the application is for a new program that
>contains the new project.  The application doesn't make that bit clear,
>though.

In looking through the documentation for incubating [1], there doesn¹t
seem to be any mention of also having to be associated with a program. Is
it a requirement that all projects belong to a program at this point? If
so, I guess we would be asking for a new program as I think that
encryption and key management is a separate concern from the rest of the
programs listed here [2].

[1] https://wiki.openstack.org/wiki/Governance/NewProjects
[2] https://wiki.openstack.org/wiki/Programs


>> Teams in OpenStack can be created as-needed and grow organically. As
>>the team
>> work matures, some technical efforts will be recognized as essential to
>>the
>> completion of the OpenStack project mission. By becoming an official
>>Program,
>> they place themselves under the authority of the OpenStack Technical
>> Committee. In return, their contributors get to vote in the Technical
>> Committee election, and they get some space and time to discuss future
>> development at our Design Summits. When considering new programs, the
>>TC will
>> look into a number of criteria, including (but not limited to):
>
>> * Scope
>> ** Team must have a specific scope, separated from others teams scope
>
>I would like to see a statement of scope for Barbican on the
>application.  It should specifically cover how the scope differs from
>other programs, in particular the Identity program.

Happy to add this, I¹ll put it in the wiki today.

>> ** Team must have a mission statement
>
>This is missing.

We do have a mission statement on the Barbican/Incubation page here:
https://wiki.openstack.org/wiki/Barbican/Incubation


>> ** Team should have a lead, elected by the team contributors
>
>Was the PTL elected?  I can't seem to find record of that.  If not, I
>would like to see an election held for the PTL.

We¹re happy to do an election. Is this something we can do as part of the
next election cycle? Or something that needs to be done out of band?


>
>> ** Team should have a clear way to grant ATC (voting) status to its
>>significant contributors
>
>Related to the above

I thought that the process of becoming an ATC was pretty well set [3]. Is
there some specific that Barbican would have to do that is different than
the ATC rules in the Tech Committee documentation?

[3] 
https://wiki.openstack.org/wiki/Governance/Foundation/TechnicalCommittee


>
>> * Deliverables
>> ** Team should have a number of clear deliverables
>
>barbican and python-barbicanclient, I presume.  It would be nice to have
>this clearly defined on the application.

I will add a deliverables section, but you are correct.


>Now, for the project specific requirements:
>
>>  Projects wishing to be included in the integrated release of OpenStack
>>must
>>  first apply for incubation status. During their incubation period,
>>they will
>>  be able to access new resources and tap into other OpenStack programs
>>(in
>>  particular the Documentation, QA, Infrastructure and Release
>>management teams)
>>  to learn about the OpenStack processes and get assistance in their
>>integration
>>  efforts.
>>  
>>  The TC will evaluate the project scope and its complementarity with
>>existing
>>  integrated projects and other official programs, look into the project
>>  technical choices, and check a number of requirements, including (but
>>not
>>  limited to):
>>  
>>  * Scope
>>  ** Project must have a clear and defined scope
>
>This is missing

As mentioned above, I¹ll add this to the wiki today.

>
>>  ** Project should not inadvertently duplicate functionality present in
>>other
>> OpenStack projects. If they do, they should have a clear plan and
>>timeframe
>> to prevent long-term scope duplication.
>>  ** Project should leverage existing functionality in other OpenStack
>>projects
>> as much as possible
>
>I'm going to hold off on diving into this too far until the scope is
>clarified.
>
>>  * Maturity
>>  ** Project should have a diverse and active team of contributors
>
>Using a mailmap file [4]:
>
>$ git shortlog -s -e | sort -n -r
>   172 John Wood 
>   150 jfwood 
>65 Douglas Mendizabal 
>39 Jarret Raim 
>17 Malini K. Bhandaru 
>10 Paul Kehrer 
>10 Jenkins 
> 8 jqxin2006

[openstack-dev] Incubation Request for Barbican

[Jarret Raim]

All,

Barbican is the OpenStack key management service and we’d like to request 
incubation for the Icehouse release. A Rackspace sponsored team has been 
working for about 9 months now, including following the Havana release cycle 
for our first release.

Our incubation request is here:
https://wiki.openstack.org/wiki/Barbican

Our documentation is mostly hosted at GitHub for the moment, though we are in 
the process of converting much of it to DocBook.
https://github.com/cloudkeep/barbican
https://github.com/cloudkeep/barbican/wiki


The Barbican team will be on IRC today at #openstack-barbican and you can 
contact us using the barbi...@lists.rackspace.com mailing list if desired.



Thanks,

Jarret Raim   |Security Intrapreneur
-
5000 Walzem RoadOffice: 210.312.3121
San Antonio, TX 78218   Cellular: 210.437.1217
-
rackspace hosting   |   experience fanatical support
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Keystone][Oslo] Future of Key Distribution Server, Trusted Messaging

[Jarret Raim]

> I also don't like that the discussions suggested that because it would be
hard
> to get Barbican incubated/integrated it should not be used. That is just
crazy
> talk. TripleO merged with Tuskar because Tuskar is part of deployment.

We are completing our incubation request for Barbican right now. I am
waiting to send it until tomorrow as I figured it woudn't get a lot of
traction right before the break.

As I've said before, I think the KDS should be part of Barbican, but if
Keystone wants to merge it sooner, I won't complain. Barbican has a pretty
full roadmap through the Icehouse release, so I doubt my team would get to
this. We'd be happy to help anyone interested in implementing it and I would
merge it, but that's up to the authors.

The public / private service argument I don't really get. The KDS will be an
internal server regardless of whether it is in Barbican or Keystone so I
don't think that is a differentiator.

> Seems to me that pulling Barbican into the identity _program_, but still
as its
> own project/repo/etc. would solve that problem.

Not sure I agree here. Key management solves many problems, some of which
are identity problems, but key management is not fundamentally an identity
service.  For example, SSL certificates for services, symmetric key
generation for at rest encryption, etc.

What do we think are the reasons for combining the two efforts?



Jarret



smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Keystone][Oslo] Future of Key Distribution Server, Trusted Messaging

[Jarret Raim]

On 11/21/13, 7:51 PM, "Jamie Lennox"  wrote:


>So i've a feeling that this was proposed and dismissed once before. I
>don't remember why.
>
>So my concern with barbican is that i'm under the impression that
>barbican was going to be an 'overcloud' service. That's a really bad way
>of putting it, but it is service and user facing and discovered via the
>service catalog. 
>
>This feature will need to be configured at a lower level (runs in
>situations without a token) and so we will need to configure the
>services to point to an IP for the KDS service.

Why would there be a need for token less authentication? My understanding
of the feature is that each service account would have a KDS key
associated with it. This means that each account would need to
authenticate to Keystone before talking to Barbican. Are there service
accounts that don’t have a keystone account?

>
>Is this an expected deployment of barbican (i can't see why not)?

We certainly could enable this if needed. We already create separate uwsgi
processes for the main and admin apis. We could create another one for the
KDS. I’d rather not do that unless we have to though.


Jarret



>
>Jamie
>
>On Thu, 2013-11-21 at 20:08 +, Jarret Raim wrote:
>> The Barbican team has been taking a look at the KDS feature and the
>> proposed patch and I think this may be better placed in Barbican rather
>> than Keystone. The patch, from what I can tell, seems to require that a
>> service account create & use a key under its own tenant. In this use
>>case,
>> Barbican can handle the entire exchange and Keystone can just provide
>> auth/auth for the process. This would allow for some great additional
>> features including guaranteed entropy and additional security through
>>the
>> use of HSMs, auditing / logging, etc.
>> 
>> Barbican is pretty far along at this point and it doesn¹t appear to be a
>> huge amount of work to move the patch over as it doesn¹t seem to use any
>> Keystone internals.
>> 
>> What would people think about this approach? We¹re happy to help move
>>the
>> patch over and I¹m certainly happy to merge it as it feels like a good
>> feature for barbican.
>> 
>> 
>> 
>> 
>> Jarret
>> 
>> 
>> 
>> 
>> 
>> 
>> On 11/21/13, 12:55 AM, "Russell Bryant"  wrote:
>> 
>> >Greetings,
>> >
>> >I'd like to check in on the status of this API addition:
>> >
>> >https://review.openstack.org/#/c/40692/
>> >
>> >The last comment is:
>> >
>> >   "propose against stackforge as discussed at summit?"
>> >
>> >I don't see a session about this and from a quick look, don't see notes
>> >related to it in other session etherpads.
>> >
>> >When was this discussed?  Can you summarize it?
>> >
>> >Last I heard, this was just being deferred to be merged early in
>> >Icehouse [1].
>> >
>> >This is blocking one of the most important security features for
>> >OpenStack, IMO (trusted messaging) [2].  We've been talking about it
>>for
>> >years.  Someone has finally made some real progress on it and I feel
>> >like it has been given little to no attention.
>> >
>> >I'm not thrilled about the prospect of this going into a new project
>>for
>> >multiple reasons.
>> >
>> > - Given the priority and how long this has been dragging out, having
>>to
>> >wait for a new project to make its way into OpenStack is not very
>> >appealing.
>> >
>> > - A new project needs to be able to stand on its own legs.  It needs
>>to
>> >have a reasonably sized development team to make it sustainable.  Is
>> >this big enough for that?
>> >
>> >What's the thinking on this?
>> >
>> >[1]
>> 
>>>http://lists.openstack.org/pipermail/openstack-dev/2013-August/013992.ht
>>>ml
>> >[2] https://review.openstack.org/#/c/37913/
>> >
>> >-- 
>> >Russell Bryant
>> >
>> >___
>> >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

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

Re: [openstack-dev] [Keystone][Oslo] Future of Key Distribution Server, Trusted Messaging

[Jarret Raim]

The Barbican team has been taking a look at the KDS feature and the
proposed patch and I think this may be better placed in Barbican rather
than Keystone. The patch, from what I can tell, seems to require that a
service account create & use a key under its own tenant. In this use case,
Barbican can handle the entire exchange and Keystone can just provide
auth/auth for the process. This would allow for some great additional
features including guaranteed entropy and additional security through the
use of HSMs, auditing / logging, etc.

Barbican is pretty far along at this point and it doesn¹t appear to be a
huge amount of work to move the patch over as it doesn¹t seem to use any
Keystone internals.

What would people think about this approach? We¹re happy to help move the
patch over and I¹m certainly happy to merge it as it feels like a good
feature for barbican.




Jarret






On 11/21/13, 12:55 AM, "Russell Bryant"  wrote:

>Greetings,
>
>I'd like to check in on the status of this API addition:
>
>https://review.openstack.org/#/c/40692/
>
>The last comment is:
>
>   "propose against stackforge as discussed at summit?"
>
>I don't see a session about this and from a quick look, don't see notes
>related to it in other session etherpads.
>
>When was this discussed?  Can you summarize it?
>
>Last I heard, this was just being deferred to be merged early in
>Icehouse [1].
>
>This is blocking one of the most important security features for
>OpenStack, IMO (trusted messaging) [2].  We've been talking about it for
>years.  Someone has finally made some real progress on it and I feel
>like it has been given little to no attention.
>
>I'm not thrilled about the prospect of this going into a new project for
>multiple reasons.
>
> - Given the priority and how long this has been dragging out, having to
>wait for a new project to make its way into OpenStack is not very
>appealing.
>
> - A new project needs to be able to stand on its own legs.  It needs to
>have a reasonably sized development team to make it sustainable.  Is
>this big enough for that?
>
>What's the thinking on this?
>
>[1]
>http://lists.openstack.org/pipermail/openstack-dev/2013-August/013992.html
>[2] https://review.openstack.org/#/c/37913/
>
>-- 
>Russell Bryant
>
>___
>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] [barbican] re: Is barbican suitable/ready for production deployment?

[Jarret Raim]

A little more detail. We cut our feature complete release along with everyone 
else for Havana M3. We are currently standing up the production environments 
for the code. So, we believe that the codebase is pretty stable, but it has not 
been run in production yet.

As John said, we're happy to help get things deployed and we'd love to have 
someone else beating on the code to find any bugs. I also end up in SF pretty 
frequently (assuming you are located there), so if you want to talk in person, 
just let me know.


Thanks,
Jarret


From: John Wood mailto:john.w...@rackspace.com>>
Reply-To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, September 25, 2013 10:10 PM
To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [barbican] re: Is barbican suitable/ready for 
production deployment?

Hello Pathik,

We are preparing the application for production usage, but it is not yet ready 
to go. We could speak further with you about your production needs if that 
would be of interest.

For evaluation purposes, we have stood up an integration 
environment.
 You could also stand up a local instance of 
Barbican. The PKCS 
based HSM plugin may be used with a SafeNet HSM as well.

Thanks,
John
-
john.w...@rackspace.com


From: Pathik Solanki [psola...@salesforce.com]
Sent: Wednesday, September 25, 2013 6:03 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [barbican] Is barbican suitable/ready for production 
deployment?

Hi Barbican Team,
My team here at salesforce.com is evaluating Barbican 
for our use case of managing secrets. The git repository indicates that 
Barbican is still in development and not ready for production deployment. I 
vaguely remember from the presentation at OpenStack Summit that 
cloudkeep/barbican has production ready code too. Please correct me if I am 
wrong and if there is some production ready instance then please point me to it.

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

Re: [openstack-dev] [Nova] FFE Request: Encrypt Cinder volumes

[Jarret Raim]

On 9/9/13 9:25 AM, "Russell Bryant"  wrote:

>On 09/09/2013 04:57 AM, Thierry Carrez wrote:
>> Russell Bryant wrote:
>>> I would be good with the exception for this, assuming that:
>>>
>>> 1) Those from nova-core that have reviewed the code are still happy
>>>with
>>> it and would do a final review to get it merged.
>>>
>>> 2) There is general consensus that the simple config based key manager
>>> (single key) does provide some amount of useful security.  I believe it
>>> does, just want to make sure we're in agreement on it.  Obviously we
>>> want to improve this in the future.
>> 
>> +1
>> 
>> I think this is sufficiently self-contained that the regression risk is
>> extremely limited. It's also nice to have a significant hardening
>> improvement in the Havana featurelist. I would just prefer if it landed
>> ASAP since I would like as much usage around it as we can get, to make
>> sure the previous audits didn't miss an obvious bug/security hole in it.
>> 
>
>The response seems positive from everyone so far.  I think we should
>approve this and try to get it merged ASAP (absolutely this week, and
>hopefully in the first half of the week).
>
>ACK on the FFE from me.


Me as well for what it's worth. While I understand the concerns around key
management, Barbican will have our 1.0 release for Havana and it should be
relatively easy to integrate the proposed patches with Barbican at that
time. Even so, the current version does offer some security and gives us
the ability to have the code tested before we introduce another moving
part.


Thanks,
Jarret Raim


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

Re: [openstack-dev] [keystone] [oslo] postpone key distribution bp until icehouse?

[Jarret Raim]

>Dolph Mathews wrote:
>> With regard
>> to: 
>>https://blueprints.launchpad.net/keystone/+spec/key-distribution-server
>> [...]
>
>Dolph: you don't mention Barbican at all, does that mean that the issue
>is settled and the KDS should live in keystone ?

Dolph and I talked about having a design session to talk about how
Barbican and Keystone will work together going forward. In this particular
case, as I understand it, Simo is right. There isn't much need for
Barbican to be involved in the PKI key signing (except maybe for key
storage at some point, but that wouldn't' require a lot of changes if we
did that).

Once the sessions are opened for Hong Kong, we'll put in for the design
session.



Jarret


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

Re: [openstack-dev] Swift, netifaces, PyPy, and cffi

[Jarret Raim]

I vote for including cffi. We are going to use a cffi lib as part of Barbican 
(key management) anyway, so I'd like to see wider acceptance.

Jarret

From: Alex Gaynor mailto:alex.gay...@gmail.com>>
Reply-To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, August 14, 2013 12:12 PM
To: "openst...@nemebean.com" 
mailto:openst...@nemebean.com>>, OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] Swift, netifaces, PyPy, and cffi

I just chatted with the Python product owner at Red Hat, he says this is going 
to make it's way to the next step later today (this past weekend was a Fedora 
conference), so this should be happening soon.

Joe: Yup, I'm familiar with that piece (I had lunch with Vish the other week 
and he's the one who suggested Swift as the best place to get started with 
OpenStack + PyPy). For those who don't know I'm one of the core developers of 
PyPy :)

Alex



On Wed, Aug 14, 2013 at 9:24 AM, Ben Nemec 
mailto:openst...@nemebean.com>> wrote:
On 2013-08-13 16:58, Alex Gaynor wrote:
One of the issues that came up in this review however, is that cffi is
not packaged in the most recent Ubuntu LTS (and likely other
distributions), although it is available in raring, and in a PPA
(http://packages.ubuntu.com/raring/python-cffi [2]
 nd https://launchpad.net/~pypy/+archive/ppa?field.series_filter=precise
[3] respectively).


As a result of this, we wanted to get some feedback on which direction
is best to go:

a) cffi-only approach, this is obviously the simplest approach, and
works everywhere (assuming you can install a PPA, use pip, or similar
for cffi)
b) wait until the next LTS to move to this approach (requires waiting
until 2014 for PyPy support)
c) Support using either netifaces or cffi: most complex, and most
code, plus "one or the other" dependencies aren't well supported by
most tools as far as I know.

It doesn't appear to me that this is available for RHEL yet, although it looks 
like they're working on it: 
https://admin.fedoraproject.org/updates/python-cffi-0.6-4.el6

That's also going to need to happen before we can do this, I think.

-Ben


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



--
"I disapprove of what you say, but I will defend to the death your right to say 
it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: 125F 5C67 DFE9 4084
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] KMIP client for volume encryption key management

[Jarret Raim]

>· Agreed that there isn¹t an existing KMIP client in python. We are
>offering to port the needed functionality from our current java KMIP
>client  to python and contribute it to openstack.

Are you taking about porting to Python or having python call a Java
wrapper?


>· Good points about the common features that barbican provides. I will
>take a look at the barbican architecture and join discussions there.

Thanks, we'd love the help.


Jarret


> 
> 
>Thanks,
>Bill
> 
> 
>From: Jarret Raim [mailto:jarret.r...@rackspace.com]
>
>Sent: Friday, July 19, 2013 9:46 AM
>To: OpenStack Development Mailing List
>Subject: Re: [openstack-dev] KMIP client for volume encryption key
>management
>
>
> 
>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. 
>
> 
>
> 
>
>Thanks,
>
>Jarret
>
> 
>
> 
>
> 
>
> 
>
>From: , Bill 
>Reply-To: OpenStack List 
>Date: Thursday, July 18, 2013 2:11 PM
>To: OpenStack List 
>Subject: [openstack-dev] KMIP client for volume encryption key management
>
> 
>
>A blueprint and spec to add a client that implements OASIS KMIP standard
>was recently added:
> 
>https://blueprints.launchpad.net/nova/+spec/kmip-client-for-volume-encrypt
>ion
>https://wiki.openstack.org/wiki/KMIPclient
> 
> 
>We¹re looking for feedback to the set of questions in the spec. Any
>additional input is also appreciated.
> 
>Thanks,
>Bill B.
>The information contained in this electronic mail transmission may be
>privileged and confidential, and therefore, protected from disclosure. If
>you have received this communication in error, please notify us
>immediately by replying to this message and deleting it from your
>computer without copying or disclos

Re: [openstack-dev] [barbican]

[Jarret Raim]

> 
>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.r...@rackspace.com]
>
>Sent: Monday, July 22, 2013 2:38 PM
>To: OpenStack Developmen

Re: [openstack-dev] [barbican]

[Jarret Raim]

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

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 
Ha

Re: [openstack-dev] KMIP client for volume encryption key management

[Jarret Raim]

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.


Thanks,
Jarret




From: , Bill 
mailto:bill.bec...@safenet-inc.com>>
Reply-To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, July 18, 2013 2:11 PM
To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] KMIP client for volume encryption key management

A blueprint and spec to add a client that implements OASIS KMIP standard was 
recently added:

https://blueprints.launchpad.net/nova/+spec/kmip-client-for-volume-encryption
https://wiki.openstack.org/wiki/KMIPclient


We’re looking for feedback to the set of questions in the spec. Any additional 
input is also appreciated.

Thanks,
Bill B.

The information contained in this electronic mail transmission
may be privileged and confidential, and therefore, protected
from disclosure. If you have received this communication in
error, please notify us immediately by replying to this
message and deleting it from your computer without copying
or disclosing it.



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

Re: [openstack-dev] Move keypair management out of Nova and into Keystone?

[Jarret Raim]

On 7/2/13 12:43 PM, "Simo Sorce"  wrote:


>On Tue, 2013-07-02 at 16:55 +, Tiwari, Arvind wrote:
>> Hi Simo,
>> 
>> I am lost.
>>  
>> Does Barbican is product came out of
>>https://wiki.openstack.org/wiki/KeyManager BP?
>
>Yes Barbican is an implementation of this Blueprint afaik.

Barbican is based on the goals of this blueprint. We revised a lot of it,
but the goals are the same. The current documentation can be found here:

https://github.com/cloudkeep/barbican/wiki

https://github.com/cloudkeep/barbican


>
>> If yes, then why it is deviating from the BP which says Key Manager
>>will be separate service but not a part of Keystone.
>
>Sorry I don't follow, Barbican is separated from Keystone.

Correct. Barbican is a separate service. We use Keystone for auth
(obviously), but we have our own infrastructure.


Jarret


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

Re: [openstack-dev] Move keypair management out of Nova and into Keystone?

[Jarret Raim]

Wrote this answer this morning, but Simo beat me to it. Answer below sent
for posterity.



TL;DR:

Jay - it seems like we are on the same page. Barbican can be helpful for
generation and storage (if needed) of various types of keying material.
However, if your use case is better served by storing the keys yourself,
than that seems fine.



On 7/2/13 9:07 AM, "Jay Pipes"  wrote:

>On 07/02/2013 09:49 AM, Jarret Raim wrote:
>> I've spent some time thinking about how Barbican (Key Management) can
>>help
>> in this workflow.
>>
>> We will have the ability to generate SSH keys (and a host of other key &
>> certificate types). This is backed by cryptographically sound code and
>> we've spent some time figuring out the entropy problem and HSM support.
>>If
>> the keys are stored in Barbican, we'd get the audit / logging and other
>> functionality needed for compliance.
>
>What does the above mean? What about Barbican is audited/logged that
>isn't in Keystone and why wouldn't such auditing/logging be added to
>Keystone if it were needed for compliance? I'm trying to figure out why
>there is yet another OpenStack-related project for storing
>keys/credentials when Keystone already exists.

Barbican has wider scope that Keystone. Keystone is the source for auth
and will store the keys that are associated for a particular user.
However, there are many reasons why keystone might not want to generate or
store keys. These include the various compliance regimes - almost all of
which have some requirements around key management (and identity). One of
Barbican's main goals is to provide the logging, auditing and reporting
needed for customers to meet their compliance obligations. Additionally,
high volume key creation can be tricky from a entropy point of view. We
will offer plugins that allow for the use of various entropy sources
(including the Intel chip stuff when it comes out) as well as support for
using a full HSM for key generation.

None of this means that Keystone couldn't be the API that other services
use to get their public SSH keys. It just means that Keystone might want
to use Barbican for key creation / storage. If we think the SSH pub key is
narrow enough use case, I don't have a problem with Keystone just storing
it.


> > We also get federation which will
>> allow customers of public Clouds (or shared private Clouds) to maintain
>> custody of their own keys rather than storing them in the provider.
>
>I don't understand. Users already have custody of their own keys. The
>only thing that Keystone/Nova has is the public key fingerprint [1], not
>the private key...

This is true for SSH key access to nova. There will be other use cases
where we might want full certificates or some other keying material tied
to a user. 

>> There seem to be a couple of ways to take advantage of this
>>functionality.
>> If a key is specific to a user, then Keystone could store a URI to the
>>key
>> in Barbican and Nova could request it on server creation. Alternatively,
>> the user could pass a URI to a key into Nova directly. If we want to
>>move
>> to always enabling SSH key access only on boot, Nova could create a key
>> under the requesting tenant in Barbican and use it on server create.
>
>OK, so the above would basically be a "driver" in Keystone parlance for
>the credentials module, where Keystone would just store the key in
>Barbican and retrieve said key.
>
>At this point, though, what exactly is the point of Barbican over a
>simple database or KVS driver?

>From Keystone's point of view, that's probably true. You can just use us a
dumb store if that makes the most sense for the use case.

For something like public SSH keys only, there is probably nothing wrong
with any type of storage (though there might be some requirements for key
auditing & rotation that need to be met). However, Barbican offers several
benefits over an internally maintained key storage service.

First, a single secure key storage service is better than each product
storing their own. This doesn't matter as much for Keystone as it is
already going to have to be secure, etc. but it does matter for all the
other Barbican customers.

Second, Barbican will always offer a free an open source implementation.
This allows any customer access to high quality, security crypto without
having to go to a vendor.

Third, Barbican will support hardware security modules, the Intel TPM and
rand stuff and other solutions for better quality / more secure crypto
products.

Fourth, Barbican is a simple ReST API that is open and doesn't require
custom code for a particular provider.

There is lots more, but you get the idea.

>> Things get more interesting when we 

Re: [openstack-dev] Move keypair management out of Nova and into Keystone?

[Jarret Raim]

I've spent some time thinking about how Barbican (Key Management) can help
in this workflow.

We will have the ability to generate SSH keys (and a host of other key &
certificate types). This is backed by cryptographically sound code and
we've spent some time figuring out the entropy problem and HSM support. If
the keys are stored in Barbican, we'd get the audit / logging and other
functionality needed for compliance. We also get federation which will
allow customers of public Clouds (or shared private Clouds) to maintain
custody of their own keys rather than storing them in the provider.

There seem to be a couple of ways to take advantage of this functionality.
If a key is specific to a user, then Keystone could store a URI to the key
in Barbican and Nova could request it on server creation. Alternatively,
the user could pass a URI to a key into Nova directly. If we want to move
to always enabling SSH key access only on boot, Nova could create a key
under the requesting tenant in Barbican and use it on server create.
 
Things get more interesting when we are talking about IPSec certificates
and the like. Barbican seems a more logical place to generate / store /
share these types of keys than Keystone.

I'm open to other options - we are going to build this type of
functionality and I'm interested in how people would like to use it.




Jarret



On 7/2/13 7:46 AM, "Jay Pipes"  wrote:

>On 07/02/2013 08:26 AM, Simo Sorce wrote:
>> On Mon, 2013-07-01 at 21:03 -0400, Jay Pipes wrote:
>>> On 07/01/2013 07:49 PM, Jamie Lennox wrote:
 On Mon, 2013-07-01 at 14:09 -0700, Nachi Ueno wrote:
> Hi folks
>
> I'm interested in it too.
> I'm working on VPN support for Neutron.
> Public key authentication is one of feature milestone in the IPsec
> implementation.
> But I believe key-pair management api and the implementation will be
> quite similar in Key for IPsec and Nova.
>
> so I'm +1 for moving key management for Keystone.
>
> Best
> Nachi

 I don't know how nova's keypair management works but i assume we are
 talking about keys for ssh-ing into new virtual machines rather than
 keys for authentication against nova.

 Keystone's v3 api has credentials storage (see
 
https://github.com/openstack/identity-api/blob/master/openstack-identit
y-api/src/markdown/identity-api-v3.md ), is this sufficient on behalf
of keystone? There is some support in the current master of
keystoneclient for working with these credentials.

 Otherwise would the upcoming barbican be a more appropriate place?

 If i've got this wrong and we are using these keys to actually
 authenticate against nova then if someone can point me to the code
i'll
 see how hard it is to transfer to keystone.
>>>
>>> Actually, no, I think you have it right (though the correct link is
>>> 
>>>https://github.com/openstack/identity-api/blob/master/openstack-identity
>>>-api/v3/src/markdown/identity-api-v3.md)
>>>
>>> I think the main work, though, has to be in removing/replacing the Nova
>>> API /keypairs stuff with calls to Keystone's v3/credentials API.
>>>
>>> Would the appropriate way to do this be to add an API shim into Nova's
>>> API that simply calls out to the Keystone v3/credentials API IFF
>>> Keystone's v3 API is enabled in the deployment? Then, deprecate the old
>>> code and when Keystone v2 API is sunsetted, then remove the old Nova
>>> keypairs API codepaths?
>>
>> I guess you also need to handle a migration of the data from one store
>> to the other ?
>> Or are these data migrations left as an exercise to the admins ?
>
>No, you are correct, a migration script should be included as part of
>the code.
>
>Best,
>-jay
>
>
>___
>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