20:00:36 <redrobot> #startmeeting barbican
20:00:38 <openstack> Meeting started Mon Apr 28 20:00:36 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:40 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:42 <openstack> The meeting name has been set to 'barbican'
20:01:02 <redrobot> Hi everybody!  Can I get a show of hands for the barbican weekly meeting?
20:01:04 <jvrbanac> o/
20:01:10 <rellerreller> o/
20:01:11 <atiwari> o/
20:01:13 <arunkant> o/
20:01:15 <peter-hamilton> o/
20:02:01 <redrobot> awesome!  looks like there's plenty of us here
20:02:13 <redrobot> as usual the agenda wiki page can be found here:
20:02:17 <redrobot> #link https://wiki.openstack.org/wiki/Meetings/Barbican
20:02:33 <redrobot> Looks like we don't have much on the agenda...
20:02:46 * redrobot quickly scans last week's minutes
20:02:57 <reaperhulk> o/
20:03:00 <lisaclark1> o/
20:03:26 <malini1> Greetings~
20:03:30 <hgedikli> o/
20:03:45 <redrobot> hi malini1 good to see you again!
20:04:11 <atiwari> redrobot, can we decide on summit agenda ?
20:04:23 <atiwari> do you guys have any thoughts ?
20:04:56 <redrobot> atiwari, unfortunately jraim won't be in the meeting today, but I'd like to have his input on that
20:05:10 <malini1> :-)
20:05:14 <atiwari> ok
20:05:44 <woodster_> I recall jarret saying eventing/notifications and plugin-architecture would be two good topics
20:06:11 <hgedikli> woodster_ i should have a blueprint by the summit
20:06:13 <woodster_> the former could accommodate auditing aspects as well as ssl cert generation related notifications for example
20:06:27 <malini1> my feeling is multiple porjects will mature and want event notification
20:06:35 <malini1> might it be a part of oslo and barbican a user
20:06:37 <woodster_> hgedikli: that sounds good
20:06:51 <malini1> anybody know of any event general purpose framework?
20:07:07 <atiwari> keystone have one
20:07:32 <rellerreller> I think Nova was talking about adding events as well
20:07:36 <redrobot> atiwari do you know if they use a library or did they write their own?
20:07:45 <hgedikli> yeah i checked out nova orchestration but i don't think it's something we can use in barbican
20:07:50 <redrobot> sounds like something that we might need Oslo's input on, then.
20:07:56 <hgedikli> we need something that can notify clients and it needs to have authentication
20:07:57 <atiwari> they have their own
20:08:01 <woodster_> I recall stacktach being used by some projects. I think ceilometer is providing some services in that area
20:08:06 <atiwari> redrobot ^
20:08:10 <nkinder> for notifications?  Keystone is using oslo.messaging
20:08:31 <nkinder> not sure if you're looking for a framework that's a level above that or not
20:08:37 <atiwari> oslo.messaging just for integration
20:09:11 <atiwari> nkinder, notification can be done without oslo.messaging
20:09:34 <hgedikli> isn't oslo messaging just an encapsulation around amqp ?
20:09:39 <atiwari> but anyways a generic solution will be awesome
20:09:47 <arunkant> oslo.messaging has both rpc and notifcation support and provides support for various brokers, rabbitmq, zeromq, qpid etc..
20:09:53 <nkinder> there are many reasons a generic solution is ideal
20:10:09 <hgedikli> yeah i was thinking users creating subscriptions to notifications (via types - whether it's a webhook, email or dropping a message to clients queue)
20:10:10 <nkinder> for example, trying to tie message security into oslo would then allow you to comsume that functionality
20:10:38 <nkinder> e-mail is a different story of course if you're talking about notification to end users (as opposed to other services)
20:10:53 <woodster_> so it seems that this area might be good to cover in atlanta :)
20:11:04 <hgedikli> well, we'll still need to attach a cert to the email so that client knows it's coming from barbican
20:11:08 <atiwari> yes good topic
20:11:09 <peter-hamilton> would subscriptions be used for something like two-factor auth down the road?
20:11:13 <hgedikli> same thing with webhook call, we need to sign the request
20:11:51 <atiwari> hgedikli please add one topick http://summit.openstack.org/
20:11:57 <hgedikli> so who'll be in the atlanta summit and where/how do we meet?
20:12:22 <hgedikli> atiwari: ll do
20:12:46 <atiwari> arunkant has good experience with keystone event notification. he can also help you on it
20:13:06 <malini1> I'll be at the Atlanta summit and plan to attend Barbican, some nova, and neutron design sessions
20:13:09 <woodster_> the team here at rackspace is going out to atlanta
20:13:10 <arunkant> for auditing, a custom notification needs to be added to generate CADF events.
20:13:38 <atiwari> I will be there
20:13:44 <nkinder> Is there a meeting agenda you're following, or is this open discussion?  I have something I wanted to discuss around security auditing whenever it's appropriate.
20:13:52 <rellerreller> A couple of us from APL will be there
20:14:00 <redrobot> hgedikli now that we're incubated we'll have dedicated space and design sessions in the official schedule
20:14:28 <malini1> Also would like to share https://etherpad.openstack.org/p/juno-key-manager-chapter, seeking input from the attendees here to guide writing of barbican chapter for security guide
20:14:45 <redrobot> nkinder, nobody updated the agenda today, so it's somewhat open.  We can talk about that next.
20:14:53 <nkinder> redrobot: ok, great
20:15:34 <redrobot> nkinder https://wiki.openstack.org/wiki/Meetings/Barbican is where the weekly agenda lives.  Feel free to add topics before the meetings.
20:16:04 <Swami> Hi folks is the Barbican also looking into storing the tenant certificates for all services
20:16:14 <rellerreller> I also have agenda item. We are looking to add a new interface into Barbican.
20:16:20 <redrobot> #agreed Event Notifications would make a great topic for the Atlanta Summit
20:16:47 <redrobot> rellerreller, k, added to today's topic queue :)
20:16:50 <atiwari> is "Barbican Secret isolation at user level" a final one?
20:17:00 <atiwari> #link http://summit.openstack.org/cfp/details/113
20:17:08 <rellerreller> redrobot: thanks
20:17:43 <atiwari> redrobot ^
20:17:48 <redrobot> atiwari I think jraim has the final say on what the official topics are.  But if even if there's no official time slot for it, we can find time to talk about it
20:18:27 <woodster_> I believe barbican will have a table where general discussion can occur, outside of the two design slots
20:18:32 <redrobot> ok, let's move on from eventing, since it seems we'll be having a lively discussion about it in Atlanta
20:18:49 <redrobot> #topic Security Auditing
20:18:51 <atiwari> ok, but this will have big impact and deserve a session :)
20:19:08 <redrobot> nkinder what were you thinking about?
20:19:43 <nkinder> redrobot: lisaclark1 send an e-mail to the dev list mentioning the security audit effort I've been driving with the integrated projects
20:19:53 <nkinder> redrobot: I started a page for Barbican last week (link coming)
20:20:08 <nkinder> https://wiki.openstack.org/wiki/Security/Juno/Barbican
20:20:17 <lisaclark1> nkinder: yes, i haven't made any other traction on our end in regards to the audit effort
20:20:23 <redrobot> #link https://wiki.openstack.org/wiki/Security/Juno/Barbican
20:20:52 <nkinder> The idea is that each project should maintain a page that covers used/implemented crypto, sensitive data handing, and other basic security info
20:21:06 <lisaclark1> if you dream it, it will come
20:21:09 <nkinder> I'm trying to get it to the point where all projects have this
20:21:12 <nkinder> lisaclark1: :)
20:21:20 <redrobot> I see, thanks for getting that started nkinder
20:21:49 <nkinder> Sure.  I'm not familiar with the barbican code in detail, so there's a lot that is still needed
20:21:58 <woodster_> the crypto stuff that is in oslo.common/incubator is interesting…every project has a snapshot in time for that I suppose
20:22:24 <redrobot> yeah... our crypto gurus are not fans of oslo crypto
20:23:08 <reaperhulk> Post-Atlanta this page might look very different, but we need to get cryptography added to global reqs first, hehe
20:23:21 <nkinder> lisaclark1 made a good point in her e-mail that it would be nice to look over all of the other projects seucrity pages (once created) to see how barbican can help
20:23:30 <woodster_> nkinder: the crypographic processing is mostly isolated to the crypto package: https://github.com/stackforge/barbican/tree/master/barbican/crypto
20:23:39 <nkinder> making a case for centralized crypto will be easier with those details collected...
20:23:45 <reaperhulk> It's a fine start, although the nature of tooling like PyKCS11 (which actually just loads a dso for communication to a third party tool) makes it hard to say exactl what is doing the encryption.
20:24:35 <nkinder> looking at "sensitive data" handling for other projects might also show some obvious things that should be stored in barbican
20:25:35 <Swami> nkinder: Yes neutron requires to store sensitive data for VPN service
20:25:43 <malini1> at one time we were discussing moving certificates stored in  nova to barbican
20:26:14 <peter-hamilton> malini1: how are certs handled now?
20:26:20 <nkinder> anyway, I just wanted to raise awareness of the page that I started so it can continue to be fleshed out and kept up to date
20:26:46 <malini1> it is a table in nova database.
20:27:13 <malini1> also the keys introduced to ssh into VM instances
20:27:22 <redrobot> nkinder cool, yeah, it's definitely good to stay on top of stuff like this
20:27:25 <lisaclark1> nkinder: thanks for getting it setup!  we'll take a look on our end and see if we can start fleshing out the pieces that aren't in flux for juno
20:27:58 <redrobot> Ok, let's move on to rellerreller's agenda item
20:28:00 <nkinder> sure thing!  Thanks for showing interest in it!
20:28:18 <redrobot> #topic rellerreller New Interface to Barbican
20:28:27 <rellerreller> OK, I wanted to bring up a proposal we have for integrating KMIP into Barbican.
20:28:54 <atiwari> +1 rellerreller
20:28:56 <rellerreller> We submitted a few blueprints this week, and one of them in particular is probably of interest to a lot of us.
20:29:21 <rellerreller> https://blueprints.launchpad.net/barbican/+spec/support-kmip, https://blueprints.launchpad.net/barbican/+spec/create-secret-store, https://blueprints.launchpad.net/barbican/+spec/kmip-secret-store
20:29:53 <rellerreller> The second one, create-secret-store, is for our proposal to add a new abstraction for storing secrets. Currently everything is tied to the DB.
20:30:10 <atiwari> rellerreller I think the biggest problem was opensource KMIP client lib (as per jraim)
20:30:23 <rellerreller> We are creating an open source project for that
20:30:34 <atiwari> hmm
20:31:03 <rellerreller> We are working both items and hope to have both completed by the end of Juno.
20:31:05 <redrobot> rellerreller secret storage is not really tied to the DB right now.
20:31:29 <redrobot> rellerreller Yes, Barbican does store data in the DB, but it's really up to the plugin implementation whether the data is the actual secret.
20:31:59 <redrobot> rellerreller The DogTag plugin is an example of using a different storage than the Barbican provided db
20:32:01 <brich> rellerreller: will someone be using this opensource KMIP lib with one of the OASIS KMIP interops?
20:32:34 <rellerreller> So the plugins looked like they provide support for encrypt, decrypt. What other plugin is there
20:32:52 <woodster_> rellerreller: looking at this bp: https://github.com/cloudkeep/barbican/wiki/Blueprint:-Create-Secret-Store    … barbican has a pkcs11 based HSM plugin available
20:33:10 <rellerreller> I don't know about the OASIS KMIP interops
20:33:37 <woodster_> barbican is storing encrypted data that the plugins provide (such as HSM)
20:33:54 <peter-hamilton> I'm working with rellerreller on this
20:34:12 <peter-hamilton> a KMIP server handles storage of its own secrets and secret attributes
20:34:23 <woodster_> barbican realy doesn't care what data is stored from the plugin, as long as it uniquely identifies (relative to that plugin impl) the information to decrypt
20:34:26 <brich> rellerreller: Since the I in KMIP is for Interoperability, the interops are a way of keeping implementations from drifting off standard, usually happen twice a year
20:34:30 <rellerreller> So the plugin library has support encrypt and decrypt but I don't see anything about storage of the keys
20:35:15 <redrobot> rellerreller in Barbican, keys are referred to as keks
20:35:44 <redrobot> rellerreller kek_meta for example, allows a plugin to define a system for managing the keys
20:35:45 <rellerreller> Right, so I read the code as generate a key, wrap it with a kek, and store in DB.
20:36:04 <redrobot> in the most generic way, yes
20:36:09 <peter-hamilton> if I follow the plugin architecture, Barbican would outsource encrypt/decrypt of secrets to a KMIP server and store the encrypted data in the database
20:36:31 <redrobot> but we're very loose on what "encryption" in the plugin sense means.
20:36:35 <rellerreller> See I don't want my keys to be generated and stored on the HSM. I don't want to wrap them and store them in the DB.
20:36:48 <rellerreller> I do want my keys...
20:37:03 <peter-hamilton> KMIP support would store the secrets externally
20:37:18 <reaperhulk> rellerreller: the current plugin infra supports that exact behavior if desired. You can store only a pointer to the key inside the HSM of your choice.
20:37:20 <redrobot> the plugin's response doesn't need to be the cryptographic encryption of the data.  the only requirement is that the plugin be able to produce the original data when given the stored "encrypted" blob
20:37:38 <peter-hamilton> Barbican would provide auth support to something like Keystone and then fetch the secret from a KMIP server
20:37:39 <reaperhulk> That said, there is plenty to talk about around KMIP and clearly there's significant confusion about the capabiities of the current plugin infra so this sounds like something we should budget time for in person
20:38:13 <reaperhulk> I personally want a plugin capable of speaking KMIP because PKCS11 is annoying and out of date (although it is now under active maintenance again)
20:38:14 <rellerreller> Ya, I guess I'm confused about the plugin architecture then
20:38:33 <peter-hamilton> hmm, i am as well
20:38:43 <rellerreller> Is there a summit talk on this?
20:38:54 <rellerreller> Or in the discussion for one?
20:39:15 <reaperhulk> Not an official talk but it definitely sounds like we need to put something together and just schedule a time to go over it in our space
20:39:47 <reaperhulk> I forget how to work the IRC bot redrobot, can you minute that?
20:40:00 <woodster_> rellerreller: yeah the client's data encryption key and the internal key encryption key are a bit confusing…but I think by 'key' in your blueprint you mean the former. It might be helpful for you to detail the sequence of steps you envisioned between barbican and the hsm
20:40:18 <woodster_> ….here that is: https://github.com/cloudkeep/barbican/wiki/Blueprint:-Create-Secret-Store#description
20:40:28 <redrobot> #action We need to make time during the Summit to talk about Barbican's Plugin Infrastructure
20:40:48 <woodster_> I believe that is the other design summit jarret wanted to have
20:41:43 <rellerreller> We have some details of the sequence of events in our bps. We are working to add more detail on those, but I think we have a good start.
20:43:08 <rellerreller> So, that's all I have. I wanted to bring this up. It sounds like I need to sync up in the IRC with some of you.
20:43:17 <redrobot> I think we also need to beef up our plugin documentation.  I especially want to document the stuff that the DogTag team has been doing.
20:43:53 <woodster_> yeah, this is dated now: https://github.com/cloudkeep/barbican/wiki/Blueprint:-Plug-in-Encryption
20:44:11 <malini1> redrobot :-) these leads to our need to write up our book chapter sooner than later and capture all of this! Sorry for falling off the planet the last 2 weeks -- travels
20:44:42 <atiwari> redrobot, reaperhulk can we make some progress on #link https://review.openstack.org/#/c/82189/ that will aslo change the crypto contract
20:45:25 <woodster_> malini1: We've been trying to move tech docs here: https://wiki.openstack.org/wiki/Barbican  Are you thnking along those lines though?
20:45:54 <reaperhulk> yep I've been looking through that today. Oh and it looks like gerrit unconfused itself so the diffs are accurate now
20:45:58 <redrobot> woodster_ I think the OpenStack guidelines require us to have very technical stuff in sphynx in our repo
20:46:03 <woodster_> atiwari: agreed on teh crypto changes. I think there might be further changes needed once we meet in atlanta.
20:46:45 <atiwari> woodster_ then what are the plan for #link https://review.openstack.org/#/c/82189/?
20:46:54 <malini1> woodster_ -- thinking along the lines of #link http://docs.openstack.org/security-guide/content/ch024_authentication.html
20:46:59 <atiwari> wd it be in before summit?
20:47:10 <malini1> got started on #link https://etherpad.openstack.org/p/juno-key-manager-chapter
20:47:25 <malini1> updating it from snippets of today's meeting
20:47:43 <malini1> atiwari -- not before summit
20:48:14 <atiwari> malini1 did you look at https://review.openstack.org/#/c/82189/?
20:48:25 <woodster_> atiwari: I think it helps us fine tune the design for sure, but it might be good to keep as a work in progress until the summit I think. Others may disagree though
20:48:46 <malini1> woodster : lot of your docs would be pulled into the book chapter, nice stuff there!!
20:49:36 <woodster_> malini1: think the challenge now that barbican is incubated is finding the right home for various docs and material
20:49:41 <malini1> atiwari -- will look today
20:50:00 <atiwari> woodster_ in my opinion we should move on with this change before summit
20:50:10 <malini1> woodster -- agree to your comment
20:50:15 <atiwari> reaperhulk what do you say?
20:50:50 <reaperhulk> I'm not going to block this change on the summit, but I can't say whether or not I think it's merge ready yet since I haven't finished review.
20:51:11 <atiwari> reaperhulk correct
20:51:23 <atiwari> it is ready for your review though :)
20:52:29 <woodster_> atiwari: we should all definitely keep reviewing in earnest. But it puts code at teh heart of barbican so it take a bit more time :)
20:53:08 <atiwari> woodster_ I know
20:53:27 <redrobot> Alrighty guys, we're running out of time for the meeting today.
20:53:34 <atiwari> I would appreciate if we can trun it before summit
20:55:23 <redrobot> Remember to add Agenda items to the wiki page when you get a chance.
20:55:35 <redrobot> See you guys next week!
20:56:12 <redrobot> #endmeeting