20:00:10 <dave-mccowan> #startmeeting Barbican
20:00:12 <openstack> Meeting started Mon Oct 10 20:00:10 2016 UTC and is due to finish in 60 minutes.  The chair is dave-mccowan. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:15 <openstack> The meeting name has been set to 'barbican'
20:00:26 <dave-mccowan> Hello Barbicaneers!
20:00:32 <dave-mccowan> #topic roll call
20:00:36 <diazjf> o/
20:01:08 <alee> o/
20:02:12 <kfarr> o/
20:02:48 <dave-mccowan> the few, the proud, the dedicated meeting attendees \o/
20:03:06 <dave-mccowan> small group, short agenda today.
20:03:15 <dave-mccowan> as usual the agenda is here:
20:03:25 <dave-mccowan> #link https://wiki.openstack.org/wiki/Meetings/Barbican#Agenda
20:03:35 <dave-mccowan> #topic action item review
20:03:54 <woodster_> o/
20:04:27 <dave-mccowan> i don't have an update on these.  i think we might need to reboot on the action items at the summit.  (most of the AIs are left over from the midcycle)
20:04:48 <dave-mccowan> does anyone have an action item update?
20:04:59 <dave-mccowan> or know of an action item that needs action by me or someone else?
20:06:25 <dave-mccowan> #topic upcoming design summits
20:06:48 <dave-mccowan> #link https://etherpad.openstack.org/p/barbican-ocata-design-summit
20:06:50 <dave-mccowan> https://etherpad.openstack.org/p/barbican-pike-ptg
20:06:51 <dave-mccowan> #link https://etherpad.openstack.org/p/barbican-pike-ptg
20:07:52 <dave-mccowan> please update the the barcelona wiki page with any more session ideas.  i'll roughly slot them in our available times.
20:08:16 <dave-mccowan> save the date in February for the Pike Design Summit in Atlanta.
20:08:48 <dave-mccowan> any thoughts or comments on these?
20:09:40 <dave-mccowan> moving on to the good stuff....
20:09:52 <dave-mccowan> #topic LBaaS user context
20:10:06 <dave-mccowan> https://bugs.launchpad.net/barbican/+bug/1592612
20:10:06 <openstack> Launchpad bug 1592612 in neutron "LBaaS TLS is not working with non-admin tenant" [Undecided,New]
20:11:02 <dave-mccowan> a couple weeks ago someone dropped in the channel saying that LBaaS was broken.  someone helped debug it.  i think it's working as designed (after all the other bug fixes have been patched).
20:11:28 <dave-mccowan> but, if you see in the launchpad comments, @johannes has an idea to save user context for LBaaS.
20:12:09 <dave-mccowan> any thoughts on this?  (i see to recall a long discussion on this eons ago maybe?)
20:12:37 <johnsom> o/ from LBaaS/Octavia  Just joining
20:13:00 <dave-mccowan> hi johnsom !
20:13:04 <sbalukoff> Also just joining
20:13:13 <sbalukoff> (Also from LBaaS / Octavia )
20:13:19 <woodster_> dave-mccowan: I mentioned this but in the LBaaS channel
20:13:26 <woodster_> but -> bug
20:14:24 <woodster_> is the ask to save user info on the container or consumer?
20:14:48 <dave-mccowan> is this something we want to do?  (i guess the code won't be in barbican.  but it would be nice to have cross-project gates and documentation so everyone knows how this is supposed to work and that it stays working)
20:15:40 <dave-mccowan> woodster_ i think the suggestion is to save the user context from the client and pass it through LBaaS, then through Barbican/Castellan client, to get permissions to the container and secrets.
20:16:25 <sbalukoff> Which client in this case?
20:16:37 <sbalukoff> The neutron client? The barbican client?
20:16:48 <dave-mccowan> now, the barbican user has to define an ACL to give the LBaaS user (admin/admin by default) access to the secret.
20:17:09 <sbalukoff> That's correct.
20:17:13 <dave-mccowan> the neutron client, i guess.  whatever starts the LBaaS listener i think.
20:17:15 <sbalukoff> It's also a pretty terrible user experience.
20:18:12 <sbalukoff> So, part of the problem here lies in the fact that LBaaS / Octavia may need to access the secrets at a time when the user isn't actively deploying a load balancer that requires a secret. That is to say, in a fail-over situation, LBaaS / Octavia will need to access the secret.
20:18:32 <dave-mccowan> sbalukoff johnsom is there ask of barbican on this?  i think the change will all be in neturon, right?
20:18:34 <sbalukoff> So, when you say, "save the user context" do you actually mean we save something to the database?
20:18:44 <johnsom> But failover would work if they granted us permission to the container right?
20:19:15 <johnsom> I have not seen this bug before, so I'm still coming up to speed on it, sorry.
20:19:40 <woodster_> I recall the idea of ACLs was to grant specific users access to secrets...so the user grants the LBaaS service user access correct?
20:19:56 <sbalukoff> woodster_: Yes, and by default that's admin/admin
20:19:59 <sbalukoff> However!
20:20:12 <sbalukoff> A normal user might not know the admin's ID.
20:20:20 <sbalukoff> And the ACL system works off IDs and not names.
20:20:38 <johnsom> If I understand right, the proposed fix is to take the user context and use that to add permission for the LBaaS account to access the content.  Is that what I'm hearing here?
20:20:41 <sbalukoff> (that's the second bug referenced and called a "scary hack" in the one you linked.)
20:21:19 <sbalukoff> Yeah, if we use the user's credentials to create an ACL on their behalf, that would work.
20:21:43 <sbalukoff> And yes, to do this we'd need the context passed through somehow.
20:22:40 <woodster_> I recall that coming up early on in discussions with rm_work. I thought the idea was to go thru a UI to upload the secret (sorry, thinking Rackspace workflow here, but could be Horizon), and then that intermediate service would stamp the right user info on there. Sorry, it's been a long time :\
20:22:52 <sbalukoff> And in any case, that seems less scary than turning the 'neutron' user into a key admin account in barbican that can simply access all secrets on any project without having to have permission explicitly granted.
20:23:35 <johnsom> Yeah, I don't want Octavia to have open access to barbican content.  It kind of defeats the purpose.
20:23:50 <woodster_> I also recall rm_work wanting to have another role introduced to barbican, like a secret-reader role, to restrict this access
20:24:00 <sbalukoff> I also don't want to make deploying TLS-terminated load balancers something that can only be done through the UI.
20:24:13 <woodster_> sbalukoff: makes sense
20:24:41 <johnsom> Yeah, sadly we just missed rm_work being online by a few hours.
20:25:37 <johnsom> Ok, reading through this.  I think you are right that this is more of an LBaaS/Octavia bug than Barbican at this point.  I have added Octavia to the projects affected
20:26:02 <dave-mccowan> do we want to take some time to research and understand history?  we can follow up later on IRC or at the summit.
20:26:49 <johnsom> Yes, probably a good idea.  The three of us, rm_work included will be at the summit
20:27:42 <dave-mccowan> johnsom great!  we can give time in a barbican work session, if that's the right place.
20:27:54 <johnsom> Ok, sounds good
20:28:06 <johnsom> Is that time slot scheduled already?
20:28:50 <sbalukoff> Er... also, if y'all could make time to handle this bug, this would help solve a security concern for us: https://bugs.launchpad.net/barbican/+bug/1629511
20:28:50 <openstack> Launchpad bug 1629511 in Barbican "API get requests should list secret owner's project_id" [Undecided,New]
20:28:51 <dave-mccowan> not specifically, we can use part of one of our friday sessions: https://etherpad.openstack.org/p/barbican-ocata-design-summit
20:29:33 <sbalukoff> (Sorry to switch subjects on you; But... eh... since we're here, and you're here and we have your ear....)
20:29:34 <johnsom> Ok, I will watch that space.
20:30:13 <dave-mccowan> #topic add more owner info to secret meta data
20:30:32 <dave-mccowan> #link https://bugs.launchpad.net/barbican/+bug/1629511
20:30:32 <openstack> Launchpad bug 1629511 in Barbican "API get requests should list secret owner's project_id" [Undecided,New]
20:30:48 <dave-mccowan> woodster_, thoughts?
20:31:29 * woodster_ taking a look....
20:32:13 <dave-mccowan> sbalukoff thanks.  we'll look at it.
20:32:23 <dave-mccowan> #topic postgres SQL bug fix
20:32:48 <dave-mccowan> https://review.openstack.org/#/c/383577
20:33:07 <dave-mccowan> we need some reviews on this one ASAP.  it turns out we've been broken using postgres database for a while now.
20:33:15 <dave-mccowan> that patch should fix it.
20:33:52 <sbalukoff> dave-mccowan: Thanks! Ok, I'mma go back to my LBaaS corner. Have a good rest of your meeting, eh!
20:34:31 <dave-mccowan> sbalukoff johnsom thanks for joining.  now i know i can always summon you with the term "lbaas" :-D
20:34:42 <woodster_> dave-mccowan: adding metadata to the response doesn't seem bad to me. It'd be an issue if were were defcore certified (would require a version bump) but don't think that affects us. We'd just have to make sure the client don't break adding this data to the response
20:34:48 <johnsom> Sure, NP
20:35:01 <woodster_> johnsom: sbalukoff take care
20:35:10 <diazjf> dave-mccowan just reviewed the SQL bug fix, Looks Good :)
20:36:04 <dave-mccowan> #topic any other business
20:38:03 <dave-mccowan> woodster_ sounds like a good Ocata blueprint.  i don't think it's something we can backport, even though it addresses a security concern.
20:38:06 * woodster_ would be nice to have a PostgreSQL gate test :)
20:38:22 <diazjf> dave-mccowan seems as though theres an error with the postgre gate. I merged https://review.openstack.org/#/c/383577 since its valid and does not affect MYSQL gate
20:38:50 <woodster_> dave-mccowan: not sure about the backport side of things
20:39:10 <dave-mccowan> woodster_ there's an experimental gate job for postgres now.  i just kicked off a test of it before the meeting.
20:39:20 <woodster_> dave-mccowan: nice!
20:39:45 <dave-mccowan> http://logs.openstack.org/77/383577/1/experimental/gate-barbican-simple-crypto-devstack-dsvm-postgres/97562fd/
20:41:10 <dave-mccowan> still needs some debugging
20:41:19 <dave-mccowan> here's another run, that seemed to get farther.
20:41:20 <dave-mccowan> http://logs.openstack.org/99/381099/1/experimental/gate-barbican-simple-crypto-devstack-dsvm-postgres/f3c23a7/console.html
20:42:30 <dave-mccowan> that's all i have this week.  thanks!  see you all later!
20:43:11 <dave-mccowan> #endmeeting