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