20:00:42 #startmeeting barbican 20:00:42 Meeting started Mon Nov 9 20:00:42 2015 UTC and is due to finish in 60 minutes. The chair is redrobot. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00:43 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:00:46 The meeting name has been set to 'barbican' 20:01:05 #topic Roll Call 20:01:12 o/ 20:01:14 o/ 20:01:14 o/ 20:01:14 o/ 20:01:17 o/ 20:01:24 o/ 20:01:32 o/ 20:01:38 o/ 20:01:41 \o/ 20:02:03 woot! 20:02:09 lots of barbicaneers here today 20:02:17 as usual the meeting agenda can be found here: 20:02:20 #link https://wiki.openstack.org/wiki/Meetings/Barbican 20:03:23 #topic Tokyo Summit Recap 20:03:28 #link https://etherpad.openstack.org/p/barbican-m-design-sessions 20:03:33 #link https://etherpad.openstack.org/p/mitaka-barbican-roadmap 20:03:39 #link https://etherpad.openstack.org/p/mitaka-barbican-federation 20:04:26 I think the hottest topic at the Summit was definitely Federation 20:04:39 There was a lot of good discussion 20:04:43 o/ 20:06:07 the other big topic was the splitting of CA features into a separate project 20:06:25 but given that nobody is actually willing to do the work, I'm not going to spend any more time talking about it 20:06:55 :( 20:07:44 we saw an uptick on Barbican interest 20:08:06 also we had a chance to talk to some folks in the Designate team about a new use case for Barbican 20:08:32 and we found out that there's Barbican deployments in the wild :-O 20:09:53 o/ 20:11:03 We also talked about Marshall a bit 20:11:30 and our recommendation to the Marshall contributors is to continue to develop outside of the Barbican or Security projects 20:12:08 anything else I missed that would be worth mentioning? 20:12:32 The Marshall team welcomes all contributors, if anyone wants to be a "founder". ping me and I can get you in touch. :-) 20:13:24 ok, moving on 20:13:27 redrobot bring your own key was a hot potato 20:13:52 rellerreller yeah, I saw the IBM folks added an agenda item to talk about it in a bit 20:14:07 #topic Substitute PTL 20:14:32 any summary about Anchor and other CMS projects vs barbican CMS? 20:15:01 I'm going to be taking off for about 3 weeks starting Wednesday next week 20:15:13 and I'm looking for someone to chair the Nov 23 and Nov 30 meetings 20:15:20 does anyone want to volunteer? 20:16:19 woodster_ the Security folks agreed it would be good to write up the differences between Anchor, Killick and Barbican, but AFAIK nobody signed up to do it. 20:16:27 redrobot I don't mind. 20:16:45 Maybe I should ask what that entails first. 20:17:07 rellerreller basically running this meeting. :) 20:17:26 That seems easy enough. 20:17:59 rellerreller possibly coordinate the release of MItaka-1 20:18:07 * redrobot checks Mitaka release schedule 20:18:35 Oh, I don't know much about releasing the software. 20:18:46 Yeah, Mitaka-1 milestone is due on Dec 1-3 20:19:19 I don't think I'm a good person for that. I don't know anything about that stuff. I can run a meeting easy enough. 20:19:36 redrobot, is it as easy as putting in the merge request for the release team to do it? 20:19:52 kfarr that's a good question... 20:20:05 Historically the Release Manager(s) hang out in #openstack-release 20:20:30 and ping the PTL (or release liaison) to ask if the project is ready for release 20:21:07 kfarr I'll ask if a merge request would be a good way to do a milestone release and get back to you 20:21:29 redrobot ok! 20:21:31 #action redrobot to ask Release Managers if mitaka-1 will be a CR release 20:21:57 #info rellerreller will be meeting chair on Nov 23 and Nov 30 20:22:36 kfarr does that mean you could possibly be the release liaison for mitaka-1 ? :D 20:23:18 redrobot, maybe! I want all the details before I commit 20:23:18 She did know the right questions to ask. 20:23:39 kfarr hehe, fair enough, I'll have the details for next week's meeting for sure. 20:23:44 ok, moving on 20:23:59 #topic Federation Use Cases 20:24:38 one of the take-aways of the Federation discussions was that we needed more concrete use cases, and both IBM and Rackspace were going to work on getting Use Cases documented 20:24:56 silos diazjf I'm guessing you guys have made some progress on that? 20:25:26 redrobot correct, we created an etherpad as seen here: https://etherpad.openstack.org/p/barbican-federation-use-cases 20:26:15 There are annotations for compliance on the page if anyone wants to check it out. 20:26:45 diazjf awesome, I'll forward this to Joe 20:27:17 A high level summary of the Federation discussions: 20:28:00 We're calling "Federation" the feature of Bring Your Own Key (BYOK) to OpenStack clouds 20:28:13 There's two models we could use 20:28:39 Push Model: Basically a user would send the required key along with the request for an operation that requires the key. 20:28:41 Is federation really the same thing as bring your own key? 20:30:03 Pull Model: A user would grant access to their device to the cloud. The cloud service that needs a key would reach into the users' device to get the key when needed. 20:30:17 there's advantages and disadvantages to both. 20:30:24 I think BYOK would some how fall under BYOD if you can associate a key on your private device to a resource on the public cloud. 20:30:29 rellerreller arguably they could be different 20:30:55 rellerreller Rackspace is interested in BYOK, and we think Federation may be a way to provide it 20:31:53 ok. Just raising the question. Don't need an answer now. I'm still trying to organize things in my head. 20:31:55 the interesting thing about BYOK is that both Azure and AWS claim to have it, yet the two are vastly different 20:32:37 redrobot, I'd like to see these models fleshed out in a little more detail -- with an example say of retrieving a key for volume encryption 20:32:47 +1 20:32:50 edtubill that's one way of thinking about BYOK... but if you look at the AWS model, they don't really care whether the user has a device or not... they only care that the user can provide the key when needed. 20:32:54 redrobot, right now - all the terms are pretty fuzzy 20:33:24 and for the push case, for instance, its not clear to me how barbican need be involved at all .. 20:33:26 alee_ I agree. I think walking through that use case in particular may prove to eliminate some of the complexities that are being proposed. 20:33:52 Box also an interesting BYOK model: http://www.infoworld.com/article/2882030/encryption/box-you-can-bring-your-own-keys-to-encrypt-in-our-cloud.html 20:34:18 I recall the push case was probably a no go, as it would require a lot of changes to existing services to support it 20:34:34 rellerreller, redrobot, we can create more detailed use-cases with Models and review them during the next meeting 20:34:40 I agree a detailed set of use case sequences would be helfpule 20:34:46 ...or even helpful 20:34:50 These were just meant to be high-level 20:35:06 diazjf: sounds good 20:35:17 woodster_ the push model still had significant hurdles. 20:35:39 alee_ agreed. someone did mention that push model would not necessarily need Barbican at all 20:35:50 woodster_ the biggest one was how to get the key from the service that is invoked with the key to the actual service that does the work. 20:36:24 redrobot I don't think push or pull model would need to involve Barbican for byok. 20:36:56 If the key location is stored in metadata then can use Barbican, KMIP, etc. 20:37:10 Our reasoning for wanting Barbican in the mix, is that BYOK In other clouds is putting the burden of key management on the user 20:37:22 rellerreller: I think the linked-secret was required in Barbican? 20:37:33 and Barbican, being a key management service, would help users with that burden 20:38:17 woodster_ it was proposed as a solution, but we never walked through the sequence of events to prove that it was needed. 20:38:20 woodster_ that was just one possible solution... I'm not convinced linked-type is the only way to achieve BYOK 20:38:50 Meaning I don't know that it is needed. I think people were solving a problem that did not exist, but I could be wrong. 20:40:14 guys, while this is all interesting -- we need to see some sequence diagrams to define the use cases and the actual problems -- it feels like we're going around and around in conversation .. 20:40:55 alee_ :) 20:40:56 * woodster_ maybe we need a special content type to indicate a key is federated? 20:41:15 that was for alee_ :) 20:41:23 woodster_ that was the idea in the proposed links idea. 20:41:29 * alee_ aiming a missile Texas -way .. 20:41:37 hehe 20:41:56 I'll review the use cases that diazjf and edtubill documented 20:42:16 and pass them along to Joe Savak 20:42:36 #action redrobot to review use cases documented by diazjf and edtubill 20:43:02 #action diazjf to document lower-level sequence diagrams 20:43:08 woodster_ rellerreller, see https://etherpad.openstack.org/p/mitaka-barbican-federation at the end. We discussed at the summit that they would effect Castellan 20:43:22 redrobot, you got it! 20:43:27 How many of these use cases are actual (meaning customers are asking for this) vs. they sound like they could be useful? 20:44:15 For instance use case 3 of customer scaling? 20:44:59 #1 is the main use case that we want to meet and the other are just for consideration 20:46:13 edtubill thanks 20:47:59 ok, moving on 20:48:04 #topic Mid-Cycle 20:48:17 We started the mid-cycle conversation at the end of the Summit 20:48:54 as usual, we would like to have the Security and Barbican Mid-cycles in the same place, so that people who are interested in both can plan travel to just one place 20:49:44 but it's always challenging to coordinate 20:50:31 #info the proposed date for the mid-cycle is January 11-15 20:50:47 There's a few options for location 20:51:03 1. Rackspace Castle in San Antonio, TX 20:51:14 2. APL in Laurel, MD 20:51:30 3. HP campus in Seattle, WA 20:53:14 redrobot, what happened to RDU? Did you guys decide against that after I left? 20:53:16 I think we have the most Barbican contributors in the San Antonio/Austin area, so my preference would be for #1 20:53:49 redrobot, I'll see if we can get approval for IBM(Austin) to host it 20:54:39 diazjf we had the last mid-cycle in Austin, and since the next summit is in Austin, I was thinking SA would be better.... but I'm not totally opposed to it 20:55:38 diazjf, agreed! I'd like to see the RackSpace Headquarters 20:55:52 redrobot ^ 20:55:57 alee_ I think the Security folks were leaning towards APL or Seattle... I'll float RDU by them though 20:56:33 redrobot, just curious thats all .. I remember Raleght being in the mix when I left for the airport 20:56:40 maybe we should set up a Surveymonkey with all locations 20:57:08 redrobot, if it isn't , I wont bother looking into permissions to host etc. 20:57:16 redrobot if APL is chosen then I would need to know soon, so I can try and reserve space. 20:57:25 Mountain View & San Jose were also thrown out there 20:57:55 Sounds like alee_ has same concerns as me. When were you and Rob planning to make a decision? 20:58:10 oh yea... last word in Tokyo was to try to sync with Rob Clark and the Security Group. He was going to look in to space at HP Seattle for us. 20:58:10 redrobot ^ is for you. 20:58:22 rellerreller I'm hoping soon... I sent him an email today and am waiting on a reploy 20:58:32 reply even 20:59:35 security group's weekly meeting is on Thursdays, so that's probably the soonest we can get feedback from security project team. 21:00:14 also historically, we've never actually been able to coordinate the joint mid-cycle... :( 21:01:26 aaaand we're way over on time 21:01:35 thanks everyone for coming! 21:01:43 should have more info on mid-cycle next week 21:01:46 #endmeeting