20:01:15 <redrobot> #startmeeting barbican 20:01:16 <openstack> Meeting started Mon Oct 20 20:01:15 2014 UTC and is due to finish in 60 minutes. The chair is redrobot. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:01:17 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:19 <openstack> The meeting name has been set to 'barbican' 20:01:49 <redrobot> Agenda can be found here: 20:01:51 <redrobot> #link https://wiki.openstack.org/wiki/Meetings/Barbican 20:01:55 <redrobot> #topic Roll Call 20:02:00 <chellygel> <( ^______^ )^ 20:02:06 <rellerreller> o/ 20:02:08 <mattvryan> o/ 20:02:11 <jvrbanac> _o/ 20:02:13 <woodster_> \o 20:02:14 <bubbva> 0/ 20:02:20 <hyakuhei> o/ 20:02:25 <atiwari> o/ 20:02:29 <tkelsey> o/ 20:02:42 <SheenaG1> o/ 20:02:58 <redrobot> Awesome, lots of barbicaneers here 20:03:11 <redrobot> so, we don't actually have anything on the agenda. 20:03:30 <jvrbanac> lol 20:03:52 <redrobot> I'm sure there's thing we want to talk about. 20:04:05 <redrobot> #topic Integration Patterns 20:04:23 <redrobot> rellerreller was talking about different patterns that other projects are using 20:04:27 <redrobot> last week 20:05:55 <hyakuhei> Integration for what? Using Barbican Keymat? 20:06:07 <rellerreller> redrobot Giuseppe asked about Cinder integration. I responded to that email. 20:06:31 <hyakuhei> It's a slightly confusing landscape at the moment 20:06:36 <rellerreller> So Barbican is trying to integrate with different projects. 20:06:43 <redrobot> so the question was if there's a need for a common interface to a key manager, for which barbican is one implementation. So other projects could use plugins to talk to other key systems directly. 20:07:11 <rellerreller> Nova and Cinder both have a KeyManager abstraction in place. It is an abstract class. Barbican is one of the implementations of it. 20:07:38 <woodster_> would that code reside in its own repo, or part of the barb client repo? 20:07:38 <rellerreller> In Neutron they talk directly to Barbican instead of going through the KeyManager interface. 20:07:55 <woodster_> ...that key manager facade that is 20:08:13 <rellerreller> I would like to see it in Oslo 20:08:15 <alee> Iwould think that if we had a KeyManager, that it would reside in Oslo .. 20:08:23 <woodster_> makes sense 20:08:25 <hyakuhei> alee: +1 20:08:33 <hyakuhei> A few people have asked me about that recently 20:08:35 <rellerreller> We tried to push it into Oslo 1-2 years ago but failed. 20:08:57 <dhellmann> who would the review team be for a key manager library? 20:09:10 <hyakuhei> Isnt' that because oslo wants things to be established in projects first, then merged into oslo ? 20:09:18 <hyakuhei> ^ to stop endless library writing 20:09:25 <rellerreller> hyakuhei correct 20:09:44 <hyakuhei> Seems like there's a better case for oslo now than 18 months ago then :) 20:09:50 <rellerreller> But that is why it is annoying. We have duplicate code in Cinder and Nova 20:09:53 <dhellmann> rellerreller, hyakuhei: would the barbican team be the primary reviewers for this new lib? 20:10:19 * hyakuhei shrugs - dunno. 20:10:22 <rellerreller> dhellmann It would depend upon the implementation of the KeyManager. 20:10:32 <jvrbanac> woodster_, redrobot ^^ 20:10:41 <dhellmann> you might do just as well to create a library owned by the barbican team,then 20:11:03 <dhellmann> oslo isn't the only place we can create libraries, so we try to find other homes if there is an obvious review team in another program 20:11:24 <dhellmann> I can help you get set up with what you'd need, if you like. 20:11:32 <rellerreller> dhellman Is there an example of another library like this? 20:11:40 <dhellmann> rellerreller: keystone owns pycadf now 20:11:56 <hyakuhei> So obviously oslo is the preferred / good neighbour way of doing things .... 20:12:01 <atiwari> rellerreller, the abstract classes in nova and cinder are integration points for Barbican ? 20:12:14 <dhellmann> there's some discussion of a similar case for the policy library, but that doesn't really exist yet 20:12:15 <rellerreller> atiwari yes 20:12:38 <woodster_> rellerreller, are there non-barbican implementations of the key manager interface now? 20:12:42 <atiwari> that mean these projects are integrated ? 20:12:44 <dhellmann> rellerreller: I'm not saying we wouldn't take it in oslo, but if the review team would mostly be barbican devs anyway then there may not be much point 20:13:21 <rellerreller> woodster_ There is a testing KeyManager interface that simply returns the same key every time. We also had a DBKeyManager at one point as well. Again just for testing purposes. 20:13:44 <hyakuhei> dhellmann: We can get non Babrican devs from OSSG to review. 20:13:51 <hyakuhei> (Not a bad idea in any event actually) 20:14:22 <hyakuhei> I have no preference for oslo particularly, just thinking that makes sense from an integration pov. 20:14:31 <woodster_> dhellmann, if barbican owns that interface then would barbican also need to be integrated for other projects to use it, even for non-barbican purposes? If the key manager interface usages now are pending barbican integration anyway, not really an issue? 20:15:08 <dhellmann> woodster_: if the library allows alternate implementations (drivers?), then the library could be used without the barbican service being required 20:15:11 <woodster_> just trying to understand how this would fit into global requirements for projects 20:15:47 <hyakuhei> It's kind of hard to work out where support for Barbican is and isn't right now. tkelsey put together a wikipage that attempts to ssummarize where things are at. It could probably do with a review/edit from some of you guys: https://wiki.openstack.org/w/index.php?title=EncryptionInOpenstack 20:16:28 <atiwari> rellerreller, i see there are no impl. yet. 20:16:32 <tkelsey> hyakuhei: yeah it needs a lot of input, but may help build an overview 20:16:57 <hyakuhei> Would be useful to direct people to, like that ML query regarding cinder support 20:17:16 <tkelsey> hyakuhei: +1 yeah good point 20:17:22 <rellerreller> tkelsey We can take a look at that. bpoulos did a lot of work there. 20:17:25 <woodster_> dhellmann, so could this key manager facade be a library in a new repo, but under the key manager program (for review purposes) perhaps? Just trying to fit the puzzle pieces together in my head :) 20:17:31 <redrobot> I like the idea of having a separate lib for the key manager interface... would this be an oslo* lib though? 20:17:52 <rellerreller> atiwari check out the Cinder project. cinder.keymgr.barbican.py. 20:18:12 <dhellmann> woodster_: yes, you would want a new repository with just the library 20:18:18 <kaitlin-farr__> atiwari: https://github.com/openstack/cinder/blob/master/cinder/keymgr/barbican.py 20:18:43 <atiwari> rellerreller, got it I was looking in to Nova 20:18:46 <atiwari> thanks 20:18:58 <woodster_> dhellmann, ok that makes sense then. A lightweight focused repo for that feature, with barbican as an optional plugin/driver to it. 20:19:08 <dhellmann> redrobot: my suggestion right now is to have the barbican team manage the new library, since you already have an experienced review team to work on it. We could, bring some oslo folks in to give advice on the API, if you want, but we don't have to own everything that is shared. :-) 20:19:15 <dhellmann> woodster_: exactly 20:19:21 <rellerreller> Yes, Nova is still pending review. They would like to see Barbican integrated first. 20:19:33 <rellerreller> But we are still pushing on them to get it accepted. 20:20:17 <jvrbanac> dhellmann, redrobot, woodster_, sounds good to me! 20:20:20 <rellerreller> dhellman Interesting. So we would not look unfriendly by starting a new repo? 20:20:25 <woodster_> rellerreller, yes that was my concern about having barbican as a dependency for the facade...chickens & eggs! But a separate focused lib would break that condition I'd say 20:21:07 <rellerreller> woodster_ Yes. I think a separate library opens up a lot more possibilities and will make it faster to integrate. 20:21:31 <woodster_> rellerreller, for sure. 20:21:41 <rellerreller> dhellmann Interesting. So we would not look unfriendly by starting a new repo? 20:21:45 <dhellmann> rellerreller: not at all 20:21:52 <woodster_> so would this be a new stackforge repo perhaps then? 20:22:26 <rellerreller> That makes me feel better. I would hate to make the community upset, especially at the critical moment when we are trying to integrate. 20:22:42 <dhellmann> woodster_: you're an incubated project, right? I think you can make this under openstack/ 20:23:33 <dhellmann> rellerreller: I'll back you on creating the new repo for the new lib, as long as the lib supports at least one driver other than barbican just in case someone doesn't want to deploy barbican 20:24:19 <hyakuhei> Direct KMIP or somethign I suppose? 20:24:47 <woodster_> dhellmann, would it need a barbican- prefix to it though, or just declaring it as part of the key manager program would be enough? Could be as simple as 'keymanager' as the repo/lib name? :) 20:24:49 <rellerreller> hyakuhei You could do that but KMIP does not support Keystone token authentication yet 20:25:23 <hyakuhei> I'm not sure what a non-Barbican driver would look like? 20:25:35 <atiwari> redrobot, woodster_ rellerreller One more integration question, Keystone credential API. Is it make sense to proxy credentials to Barbican; to store the actual secret blob? 20:25:35 <rellerreller> All the secrets would not be validated, which is why we have KMIP under Barbican now. 20:25:38 <dhellmann> woodster_: you don't need to put barbican in the name, but "keymanager" may be a little too generic. 20:26:15 <dhellmann> hyakuhei: I'm not sure, either, but until we're certain the other projects want to rely on barbican I think you need some alternative to gain acceptance of the library 20:26:41 <dhellmann> hyakuhei: maybe a direct database driver? 20:26:47 <hyakuhei> That's fair enough, just wanted to make sure I understood 20:27:02 <woodster_> well, designing the key manager interface would be nice for Paris. Maybe a Keystone integrated mode would be optional, for projects with their own (non-Keystone auth) implementations? Paris would see like a good place to define and launch this lib then? 20:27:23 <hyakuhei> Good place to start I imagine 20:27:27 <redrobot> woodster_ +1 yeah, I think we definitely need to talk about this. 20:27:27 <rellerreller> woodster_ +1 20:27:28 <tkelsey> +1 20:27:35 <jvrbanac> +1 20:27:51 <rm_work> +1 (will there be a livestream?) 20:28:29 <atiwari> redrobot, woodster_ rellerreller did you see my question above? 20:28:35 <redrobot> rm_work not sure yet about the livestream. 20:28:57 <rellerreller> atiwari: I do not understand the question. 20:29:42 <woodster_> Adding as a topic to the kilo design summit etherpad: https://etherpad.openstack.org/p/barbican-kilo-design-sessions 20:29:53 <woodster_> (#15...a long list out there) 20:29:57 <atiwari> rellerreller, keystone define an ad-hoc strategy to store use credential. 20:30:01 <atiwari> #link https://github.com/openstack/identity-api/blob/master/v3/src/markdown/identity-api-v3.md#credentials-v3credentials 20:30:15 <rellerreller> woodster_ I think this would fall under integration with other projects as well 20:30:17 <atiwari> wondering is it make sense to move that in Barbican 20:30:48 <atiwari> keeping the keystone credential API intact 20:30:50 <woodster_> rellerreller, good point...will add to the 0-th item there! 20:31:13 <rellerreller> atiwari: I will have to look at the link and get back to you. I"m not familiar with that. 20:31:52 <atiwari> rellerreller, may be good to talk in Paris :) 20:32:04 <alee> atiwari, meaning storing the credential of the user that stored the secret ? 20:32:26 <rellerreller> atiwari, sounds good 20:32:34 <atiwari> alee, no it can be anything but scoped to user 20:34:29 <alee> atiwari, ok - I'm not sure where you are going with this. will have to read and we can discuss in paris. 20:34:45 <alee> atiwari, maybe file a spec .. 20:34:53 <atiwari> alee sure 20:34:53 <alee> or blueprint 20:34:57 <woodster_> atiwari, isn't this item #12 on the etherpad: https://etherpad.openstack.org/p/barbican-kilo-design-sessions 20:35:15 <woodster_> ...or related to it? 20:35:28 <atiwari> woodster_, it is in etherpad at last 20:35:41 <atiwari> Misc 20:37:37 <redrobot> #agreed we'll discuss a generic key manager interface library that projects can use to integrate. 20:37:56 <redrobot> do we have any other topics we need to talk about? 20:38:08 <atiwari> redrobot, woodster_, rellerreller alee any thoughts on "Generation discovery API" 20:38:09 <atiwari> ? 20:38:14 <hyakuhei> I'd like to discuss HSMs and key handling 20:38:34 <hyakuhei> tkelsey has been working on this: https://review.openstack.org/#/c/116878/ 20:38:42 <tkelsey> I would like to chat a bit about this patch https://review.openstack.org/#/c/116878 20:38:46 <redrobot> #topic HSMs and Key handling 20:38:47 <hyakuhei> Which has some interesting reviews. 20:38:51 <atiwari> this is for "How should we handle secret_store.py plugin validation" 20:39:22 <redrobot> hyakuhei go ahead 20:39:32 <hyakuhei> Basically is having a HSM but handling keyunwrapping inside Barbican allowable. 20:39:57 <hyakuhei> We're working on KMIP support that will deprecate the work tkelsey has been doing 20:40:33 <hyakuhei> My understanding is that the preferred mode of operation is for HSM to handle KEK internally and perform wrapping etc 20:40:47 <hyakuhei> With some HSM interfaces that isn't possible. 20:41:03 <hyakuhei> The ESKM only supports that through KMIP (It's _very_ KMIP complient) 20:41:15 <tkelsey> yeah KMIP is the way we are heading, however it would be good to know about the key (un)wrapping question 20:41:26 <hyakuhei> We (hp) are supporting APL with the KMIP work and setup a bunch of testing/validation systems for that 20:41:36 <woodster_> hyakuhei, would you KMIP work deprecate tkelsey's work soon, or in the longer term? 20:41:56 <hyakuhei> I'd say medium term, 1-2 cycles 20:42:23 <hyakuhei> but we want to use HSMs in high assurance environments sooner than that, without forking/doing or own addon stuff. 20:42:35 <hyakuhei> We'd rather contribute 20:42:45 <woodster_> I noticed Robert's comments out there since I put mine out there. I'd like for reaperhulk to weigh in as well. 20:43:18 <hyakuhei> woodster_: you make good points 20:43:19 <tkelsey> woodster_: I guess some of the time line depends on how soon KMIP is added to the official deps set https://review.openstack.org/#/c/114037/ 20:43:31 <hyakuhei> but I don't think security is an absolute, there are shades :) 20:44:04 <tkelsey> hyakuhei: +1 20:44:52 <woodster_> the arguments seemed reasonable to me, esp. if KMIP is a little ways off. I'll see if I can get reaperhulk's thoughts add to that CR though.... 20:45:13 <rellerreller> hyakuhei: Are you looking to store KEKs in KMIP device and then encrypt/decrypt DEKs in Barbican? 20:45:15 <hyakuhei> +1 value his input 20:45:33 <tkelsey> woodster_: thanks, input always good! 20:46:04 <hyakuhei> rellerreller: Yes, for this plugin we'd have to do wrapping in the barbican process although steps can be taken to make the KEK as short-lived as possible 20:46:32 <hyakuhei> Basically we can't do it as an internal operation to the HSM without KMIP 20:47:21 <hyakuhei> We're investing time in both as you know but we'd like to get this in first as we have some deployments that can immediately leverage it and various customer types waiting for it 20:47:44 <tkelsey> so the main question on the review page is about how the KEK is retrieved. We need to do the DEK unwrapping locally and request the KEK from the HSM on demand only when needed. 20:49:14 <tkelsey> this has some security implications, though its better than a local KEK and no HSM. Its a sort of half way solution until we can have KMIP 20:49:30 <hyakuhei> I'd also be interested in smart ideas around how to make the KEK as short-lived as possible / smart ways to purge it (given pythons various magics) 20:49:50 <tkelsey> hyakuhei: +1 yeah that would be very interesting 20:51:29 <rellerreller> I don't understand "until we can have KMIP." What happens then? 20:51:52 <hyakuhei> rellerreller: Our preferred way to interact with any HSM would be KMIP 20:52:04 <tkelsey> rellerreller: well the idea is that once we use KMIP to communicate with the HSM then we have more options 20:52:17 <hyakuhei> Which, from what I undertand, would allow us to offload keywrapping to the HSM completely 20:52:21 <woodster_> hyakuhei, so there isn't a PKCS11 sort of interface for it, correct? That's what we use with SafeNet 20:52:29 <rellerreller> But KMIP does not have encrypt/decrypt functionality as far as I know. 20:52:36 <hyakuhei> tkelsey: ? 20:54:05 <hyakuhei> I'll have to get back to you on PKCS11 20:54:18 <hyakuhei> but being slightly more abstract 20:54:55 <hyakuhei> I suppose the main difference is the level of Barbican comrpomise required to access DEKs 20:55:14 <redrobot> We're running short on time, but yeah it will definitely be interesting to discuss this at the summit. 20:55:19 <woodster_> tkelsey, hyakuhei, just trying to understand DEK vs KEK above...is DEK the secret you are encrypting with the KEK? 20:55:32 <rm_work> so, before we run out of time: python-barbicanclient 3.0 -- any idea about a release date/cutoff? I think most of the major things have merged now, right? Is the keystone session rewrite the last one that's waiting to merge? 20:55:34 <hyakuhei> In the case of on-HSM wrapping, execution would be required inside Barbican to send/receive DEKs to the HSM. 20:55:49 <redrobot> rm_work and orders... gotta get typed orders finished. 20:55:59 <rm_work> redrobot: ah, typed orders are in 3.0? 20:56:03 <tkelsey> woodster_: yes thats right 20:56:06 <rm_work> thought maybe those would be for 3.1 20:56:33 <hyakuhei> more discussion required I guess, thanks for the discussion guys 20:56:35 <redrobot> rm_work current orders don't work with Juno Final :( 20:56:35 <tkelsey> woodster_: the KEK is used to encrypt the DEK, the DEK is stored locally in Barbican, the KEK is pulled form the HSM on demand 20:56:41 <rm_work> so if you've got to finish coding that still, I'm guessing chances of getting it out before the end of the week are slim 20:57:14 <rm_work> redrobot: let me know if you have any questions about decisions I made while doing typed containers <_< 20:57:22 <redrobot> rm_work yeah, end of week would be awesome, but we need mroe reviewers 20:57:39 <rm_work> well, all I can give you is eyes and a +1, but let me know when it's up 20:57:46 <woodster_> redrobot, and you thought we had nothing to talk about an hour ago! 20:58:26 <redrobot> woodster_ hehe, yeah. 20:58:36 <redrobot> Everyon please feel free to add to the agenda on the wiki. 20:58:43 <alee> tkelsey, and when you "have KMIP", you'll be able to make an api call that does the decryption of the DEK on the HSM? 20:59:35 <redrobot> #endmeeting