20:00:11 #startmeeting barbican 20:00:12 Meeting started Mon Oct 13 20:00:11 2014 UTC and is due to finish in 60 minutes. The chair is redrobot. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00:13 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:00:16 The meeting name has been set to 'barbican' 20:01:07 Hi everyone, welcome to the Barbican weekly meeting 20:01:13 as usual the agenda can be found here: 20:01:14 #link https://wiki.openstack.org/wiki/Meetings/Barbican 20:01:18 #topic RollCall 20:01:23 o/ 20:01:29 o/ 20:01:31 \o 20:01:57 o/ 20:02:51 not a whole lot of barbicaneers here today... 20:02:56 this should be a pretty quick meeting 20:03:09 #topic Kilo Development is now Open 20:03:42 The release team has released RC1 20:03:57 which means that the master branch is now tracking Kilo development 20:04:44 I saw there's a few blueprints up for review for the Kilo cycle as well, so it seems Killo is underway 20:04:50 any questions/comments about that? 20:05:24 in case anyone is interested, this CR marks the beginning of Kilo 20:05:27 #link https://review.openstack.org/#/c/125678/ 20:06:06 ... 20:06:09 quiet group today 20:06:20 redrobot, i am working on pushing a spec for the quota implementation. will do that before tomorrow 20:08:24 tsv awesome, will try to take a look as soon as I can 20:08:32 got a backlog of stuff to read already >_> 20:09:06 redrobot, I have also move two of my spec to K branch 20:09:29 yep, I've seen that there's quite a few specs up 20:09:41 we'll definitely have plenty to talk about in Paris 20:09:49 atiwari and tsv are you guys going to Paris? 20:10:00 I am coming 20:10:19 atiwari awesome... I think I asked you that already now that I think of it. 20:10:32 :) 20:10:38 redrobot, am not. hopefully next time 20:11:09 Ok, any other topics we want to discuss today? 20:11:17 redrobot, are we finalize the summit design sessions ? 20:11:33 #topic Kilo Design Summit 20:11:44 #link https://etherpad.openstack.org/p/barbican-kilo-design-sessions 20:12:09 Per the link above, I think the following will be official Design Sessions on the schedule: 20:12:18 How to deal with multiple plugins over a system's lifetime? 20:12:31 Common Certificate Issuance API 20:13:02 Integration discussion with other OpenStack projects 20:13:13 and we'll save the 4th desing session for Kite 20:13:32 I'm really interested in "Integration discussion with other OpenStack projects" 20:13:40 rellerreller, +1 20:13:45 not set in stone yet, but I'm pretty sure that'll end up being the sessions. 20:14:05 rellerreller me too... I'll try to get that one in early in the day so we have plenty of energy :) 20:14:07 I saw the patch for Neutron. It does not follow the same pattern as Cinder and Nova. 20:14:45 I think Swift will be same as Cinder and Nova. I think it is critical to get all of them integrating in the same way. 20:15:04 Are there any special procedures or anything for getting stuff into oslo? 20:15:20 redrobot, for "Common Certificate Issuance API" do we have any spec rolling ? 20:15:56 we have stared on "https://review.openstack.org/#/c/108429/" sometime back 20:16:02 rellerreller I think stuff goes into incubator, and then we can iterate on it until it's polished and released as its own library. 20:16:02 on/one 20:16:25 atiwari I expect a blueprint to be the result of the Design Session 20:16:33 ok 20:16:59 atiwari the idea is to agree on a common set of data that can be used to provision Certificates acorss all plugins 20:17:15 redrobot, make sense 20:17:18 redrobot ? I think there is common code for integrating Barbican. I think oslo would be a good place for it. 20:17:50 rellerreller possibly... what do you have in mind? Is this the extra Key Manager façade on top of barbicanclient? 20:18:07 redrobot yes 20:19:04 I like that, so that it provides a plugin capability for any type of key manager. For instance if a hardware vendor creates a key manager that can support authenticating Keystone tokens. 20:19:18 rellerreller it's an interesting pattern. I'm actually a bit puzzled by it. I thought we envisioned Barbican to be the abstraction on top of the various keystores 20:19:37 so that integration would be done with barbicanclient directly. 20:19:52 redrobot, any plans on " User-level access to resources, such as secrets/containers" we are getting lots of interests now? 20:20:33 atiwari we'll definitely talk about it in Paris. It will be an ad-hoc discussion, since we don't have any more official design session slots. 20:20:43 redrobot It's for the use case where talking directly to hardware key store. 20:20:58 redrobot, ok 20:21:58 rellerreller it will be interesting to talk about in Paris for sure. I would argue that Barbican is similar to Keystone in that it should be THE openstack way of handling the problem domain 20:22:13 you wouldn't run your Service against a non-keystone auth layer directly 20:24:22 redrobot With the key management I can see differences. Some organizations have requirements for how keys are managed and stored. Having a non-certified entity like Barbican manage the access control may not be good enough. 20:25:17 hmm... I see your point rellerreller 20:25:27 I'm not sure yet. I feel like adding the Key Manager level on top does not add that much overhead and opens up more possibilities while supporting Barbican as the key management service. 20:26:39 I think we can table the discussion for now? It's definitely something to keep in mind, but I don't think we have enough interested parties today to fully flesh that out. 20:27:53 redrobot for sure. But I think this would be great to discuss in Paris. 20:28:21 rellerreller absoultely. I think it'll be one of the first points we touch on during the Integration Design Session 20:28:23 The difficult part with key management is that it cuts across most, if not all, of the services. 20:29:15 It's tough to get everyone on board. I don't know how we are going to do that. 20:30:58 redrobot, on KMIP implementation. what is the status? 20:31:06 I think as long as we get a majority agreement, we'll be in good shape. 20:31:24 atiwari KMIP is rellerreller's area 20:31:40 atiwari The KMIP secret store can generate and store symmetric keys 20:31:41 we have some interest in KMIP area, too. 20:31:43 I think we're close to getting pykmip into global requirements 20:32:09 We are looking to add asymmetric key support in Kilo 20:33:04 rellerreller, when we will be ready to integrate a KMIP complaint HSM. Any road map ? 20:33:06 We are also continuing to work on PyKMIP 20:34:12 atiwari So we are integrating KMIP using the secret store interface. That is working, and we can do Cinder volume encryption with a hardware KMIP device. 20:34:50 atiwari I think there is another CR for KMIP as a Barbican HSM plugin. It was under review, but I do not know the current status. 20:35:19 rellerreller, thanks I will check on that one 20:35:33 redrobot, one more question 20:35:37 atiwari https://review.openstack.org/#/c/116878/ -- this is the HSM plugin CR for KMIP 20:35:59 rellerreller, thanks 20:36:45 rellerreller, this is not KMIP 20:37:11 this our proprietary impl 20:37:37 * redrobot has not had time to review the Atalla patch 20:38:06 I thought Atalla ESKM was a KMIP device. Sorry, I was mistaken. 20:39:15 I will start on then 20:39:28 it is KMIP but this plugin is not 20:39:48 atiwari Just read this "ESKM 4.0 KMIP meets the highest standards for all KMIP versions and supports all your HP Storage KMIP enabled solutions." 20:40:33 OK, thanks for clearing that up. I was wondering how they were talking to the device. 20:41:05 ok, so ... do we have any more questions/comments for today? 20:42:30 bubbva and mattvryan do you have any questions we could answer now? 20:42:31 redrobot, yes 20:42:39 atiwari what's up? 20:42:55 redrobot: not really, just curious where we could learn more about KMIP integration (for me and hachao) 20:42:55 what is going on with FreeIPA 20:42:59 redrobot, 20:43:09 and any prep we need to do for Paris 20:43:30 redrobot, any plans to integrate with FreeIPA 20:44:05 bubbva we've currently got 3 plugins for the backend: PCKS11, KMIP, and DogTag, all with various levels of completeness. 20:44:14 great 20:44:23 redrobot one question - will webex be available for the design sessions? 20:44:29 bubbva the KMIP plugin development is led by rellerreller, so you can probably bug him with specific questions ;) 20:44:39 wil do! 20:45:01 bubbva I would be happy to discuss KMIP. 20:45:05 mattvryan I'm not sure. That's a good question though. I'll ask the TC and have an answer for you next week. 20:45:25 #action redrobot to find out if the desing sessions will be broadast 20:45:33 #action redrobot to find out if the desing sessions will be broadcast 20:45:36 rellerreller: thank you. Is there a good "starting point" for me to look to see what our plans are around KMIP? 20:45:37 redrobot ok - it looks like previous design sessions did but I couldn't find any info for this one. 20:45:49 or is it best to just work with you directly, rellerreller 20:46:42 bubbva That is a good question. Probably work directly for now. We have not posted much documentation online about KMIP and OpenStack. 20:46:45 * mattvryan admittedly didn't look very hard 20:47:50 yeah, documentation is going to be one of the areas we'll have to focus on for Kilo 20:50:40 atiwari no plans on our end for FreeIPA. I would not be opposed to a new plugin though. 20:51:28 atiwari, actually, I'm not sure we'd need a new plugin... 20:51:33 * redrobot brushes up on FreeIPA real quick 20:51:59 redrobot, OK 20:52:25 atiwari seems like FreeIPA is more of an Identity management tool than a key store? 20:52:39 it has dogtag 20:52:49 atiwari we talk directly to dogtag 20:52:56 redrobot, correct 20:53:13 atiwari what kind of use cases are you envisioning with FreeIPA? 20:53:39 for certificate provisioning 20:53:54 we can provision certificates directly from DogTag 20:53:55 o/ 20:54:03 rm_work what's up? 20:54:18 I am taking about certmonger use case 20:54:38 which deals with provisioning target 20:54:39 just arrived, saying i'm here in case you had anything you wanted to discuss re: anything I was on 20:54:54 nothing specific 20:55:05 rm_work in the nick of time... 20:55:26 * rm_work is technically on ETO today 20:55:43 atiwari I don't understand how FreeIPA fits into the big picutre... but I don't think we have time to discuss that today, since we only have 5 minutes left. 20:55:54 np 20:55:56 atiwari maybe we can bring it up again next week 20:56:00 lets take it later 20:56:30 Ok, guys. Please fell free to add Agenda topics in advance of the meeting 20:56:43 oh, I saw the patch for Neutron. It does not follow the same pattern as Cinder and Nova. 20:56:46 it definitely helps move the meeting along. 20:56:51 which is also different that LBaaS 20:56:56 need to do some coordinating 20:57:15 (sorry, trying to skim the backlog as fast as possible) 20:57:29 *different than LBaaS 20:57:41 re: my comment here: https://review.openstack.org/#/c/127823/ 20:58:05 integrating other Openstack projects is great, but we need to coordinate them all 20:58:09 or we're going to end up with a mess 20:58:58 that was my only important comment for now, I think :) 20:59:02 what about inviting a rep from each of the other interested projects to get involved in Barbican? go the other way around 20:59:10 that would be good 20:59:12 (too late to discuss :) ) 20:59:14 * rm_work is the rep from LBaaS 20:59:27 that's how we do it in the IETF 20:59:38 yeah, and I've been trying to be quite involved 20:59:47 but i haven't actually met anyone from Cinder/Nova yet 20:59:51 yep, I have it in my to-do list to reach out to all the PTLs to make sure they send someone to this design session 20:59:53 anywho, meeting end I think 20:59:57 erk 20:59:59 damnit 21:00:00 yep, thanks for coming everyone 21:00:06 #endmeeting