19:59:56 <redrobot> #startmeeting barbican
19:59:57 <openstack> Meeting started Mon Apr 13 19:59:56 2015 UTC and is due to finish in 60 minutes.  The chair is redrobot. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:59:58 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:00 <openstack> The meeting name has been set to 'barbican'
20:00:00 <chellygel> o/
20:00:05 <tkelsey> o/
20:00:10 <arunkant> o/
20:00:16 <elmiko> yo/
20:01:37 <redrobot> not a whole lot of people here yet...
20:01:44 <redrobot> let's get started anyway
20:02:04 <redrobot> as usual the Agenda can be found here:
20:02:05 <redrobot> #link https://wiki.openstack.org/wiki/Meetings/Barbican
20:02:15 <redrobot> #topic Action Items
20:02:26 <redrobot> #link http://eavesdrop.openstack.org/meetings/barbican/2015/barbican.2015-04-06-20.00.html
20:02:44 <redrobot> so I totally dropped the ball and did not get to complete any of the action items I had last week
20:02:53 <redrobot> #action redrobot to figure out why Castellan 0.1.0 tag did not get published to PyPI
20:03:00 <redrobot> #action redrobot to email dev list to get input on minor changes in the API
20:03:30 <redrobot> elmiko do you want to give an update on the Juno to Kilo migration you tested?
20:03:37 <woodster_> o/
20:03:42 <elmiko> sure thing
20:03:50 <elmiko> so i ran the migration tests
20:04:11 <elmiko> there were some issues regarding one of the statements
20:04:26 <elmiko> #link https://gist.github.com/elmiko/34c2f064c104d08a3e1f
20:04:30 <elmiko> if anyone is curious
20:04:53 <rm_work> ah o/
20:04:55 <elmiko> i tried to start with a stable juno install, then run the db-migrate with a master code base
20:05:20 <dave-mccowan> o/
20:05:25 <redrobot> elmiko I wonder if this is specific to Maria DB or if it would affect MySQL as well?
20:05:34 <elmiko> i'm not sure if there is an error in the migration. i could really use if someone else could try too
20:05:39 <elmiko> redrobot: that's a great question
20:06:01 <redrobot> I tried the migration from Juno -> Master on PostgreSQL and it seems to have worked without issues.
20:06:01 <elmiko> i can do a setup with postgresql as well, if barbican supports that
20:06:11 <elmiko> hmm, maybe it's just maria
20:06:23 <elmiko> i'll put together a true mysql setup and run again
20:06:36 <redrobot> elmiko you're awesome!  thanks.
20:06:51 <redrobot> #action elmiko to try Juno -> Kilo migration in MySQL
20:07:28 <elmiko> np, glad to help =)
20:07:41 <redrobot> I'm not sure that we support Maria DB, so if it works in MySQL we may be ok to cut RC1
20:07:57 <elmiko> k, maria is just the default for fedora
20:08:49 <redrobot> elmiko I see... I'll have to talk to xaeth (our Fedora packager) to ask what back end we'll be using in the official RPM
20:09:12 <elmiko> good call
20:09:23 <redrobot> #action redrobot to talk to Greg Swift about the DB used in the official Fedora RPM
20:10:09 <redrobot> ok, moving on
20:10:21 <redrobot> #topic Vancouver Design Summit
20:11:30 <redrobot> #link http://lists.openstack.org/pipermail/openstack-dev/2015-April/061167.html
20:11:59 <redrobot> The tentative slot allocation for Vancouver is up
20:12:21 <redrobot> We're scheduled for 3 fishbowls and 10 regular sessions
20:12:34 <woodster_> what we've done in the past is vote on the design summit wiki page which we want sessions for
20:12:50 <woodster_> #link https://etherpad.openstack.org/p/barbican-L-design-sessions
20:13:05 <redrobot> we've also got a half day on Friday
20:13:09 <redrobot> thanks woodster_
20:13:09 <alee_> o/
20:13:21 <redrobot> it would be good to figure out if we will indeed need 3 fishbowl sessions
20:13:49 <redrobot> as a reminder, Fishbowl means it's a session that is listed on the scheduled where wide community input is needed
20:14:20 <woodster_> the regular sessions are table discussion times then?
20:14:26 <redrobot> woodster_ yes
20:15:09 <redrobot> which means we may end up with some time slots where we don't have a room :-\
20:15:44 <rm_work> that's why they invented hallways
20:15:46 <redrobot> So, everyone please take a look at the etherpad that woodster_ linked.
20:15:50 <woodster_> rolling whiteboards?
20:15:58 <redrobot> I'd like to know if we do need all 3 fishbowls soon
20:16:13 <redrobot> It would be nice to give back fishbowls we may not need
20:17:29 <redrobot> woodster_ who knows...
20:17:36 <woodster_> we could add "+1"s after topics we things are interested in? Does this need to be decided before next Monday, or could we tally votes then?
20:17:57 <redrobot> woodster_ would be good to figure it out this week
20:18:19 <redrobot> Yeah, please add +1s to topics you want to discuss in the summit
20:18:24 <woodster_> so vote by COB Wednesday maybe?
20:18:39 <redrobot> woodster_ yep, that sounds like a plan
20:19:20 <redrobot> also add (Fishbowl) to sessions you think may need wide community input
20:19:44 <redrobot> and by "you" I mean all you wonderful Barbicaneers :)
20:20:11 <redrobot> any questions/comments about Design Summit planning?
20:21:13 <redrobot> ok, moving on
20:21:26 <redrobot> #topic Additional Role for per-secret ACL
20:22:09 <redrobot> So woodster_ and I were working through some per-secret ACL use cases for one of our internal barbican customers, when we noticed that the current policy does not enforce a role in addition to ACL
20:22:33 <redrobot> in other words, you don't need a Barbican role to access a secret after you've been added to the ACL
20:23:17 <redrobot> which does work, but it does not allow for an easy way to turn off access to Barbican for a user
20:23:48 <woodster_> so if a cloud admin wishes to disallow a user from accessing a Barbican secret, they have to disable their user entirely for all services I believe
20:23:49 <redrobot> one suggestion was to add a new role that is checked in addition to the ACL list
20:24:12 <arunkant> cannot we remove that user from ACL list to remove access ?
20:24:16 <woodster_> rm_work, I recall you mentioning a 'read-only-reader' sort of role
20:24:27 <rm_work> yeah, I thought that was the decision
20:24:30 <rm_work> previously
20:24:35 <redrobot> another option was to reuse the "audit" role
20:24:42 <redrobot> so, require "audit" role + ACL
20:24:44 <rm_work> redrobot: in general i am against role-reuse
20:25:11 <rm_work> roles in this sense need to be the most fine-grained units possible
20:25:29 <woodster_> arunkant, you could try to do that, but if the removal from barbican access is only temporary, then adding the user back to the original secrets would be painful
20:25:30 <rm_work> tacking things on to other things is sketchy for security <_<
20:25:32 <redrobot> arunkant yes, it's possible, but if you had a user that has ACL on 1000 secrets, you would have to remove them from all 1000 secrets individually.  Adding a role would allow for a single switch that can be turned off
20:25:35 <redrobot> rm_work why?
20:25:48 <redrobot> rm_work why are you opposed to saying that ACL requires Audit role?
20:26:00 <rm_work> redrobot: because why not make a "read_other" role?
20:26:12 <rm_work> why tack on additional unrelated functionality to a role designed for *auditing*?
20:26:26 <elmiko> +1, that makes sense to me
20:26:57 <rm_work> Just saying, I have seen this go very badly in the past (when I worked specifically doing role-based security at a previous employer)
20:27:05 <arunkant> redrobot, role is assigned per project. so if 1000 secrets are across different projects..so you have to remove assignments from all those projects
20:27:14 <redrobot> rm_work the name isn't really relevant, I think.  We would be adding a new role with the same permissions as Audit
20:27:25 <rm_work> redrobot: as long as it's a NEW role
20:27:30 <rm_work> that's what i'm saying :P
20:27:32 <woodster_> I've been viewing things as roles first, then ACL to narrow down access
20:27:38 <rm_work> name doesn't matter, just don't tie it to an existing role <_<
20:27:48 <rm_work> which was originally intended for a different purpose
20:28:07 <jaosorior> rm_work: +1
20:28:26 <redrobot> I should also point out that this only affects the default policy we include with barbican
20:28:33 <redrobot> deployers are free do to whatever they please
20:28:40 <rm_work> true, i have echoed that before as well
20:28:42 <woodster_> arunkant, that's true, but I think it would be more typical to have a project per use case, such as provisioning servers and so forth
20:28:45 <rm_work> this is all just deployer policy
20:29:25 <arunkant> woodster_, cannot we just add API to remove per project ACLs  ?
20:29:31 <rm_work> and I assumed we'd be checking "read_other" or "audit" or *whatever* it's called, in related to the reading-user's project, so there would only need to be one instance, not many <-- arunkant
20:29:52 <redrobot> arunkant why add a new API call, when we can just add a role in policy and not have to change the code?
20:29:58 <rm_work> so if i'm user1234, then read_other:user1234 && whitelisted
20:30:27 <rm_work> arunkant: and that is really messy for things like *suspensions*
20:30:37 <rm_work> where it might be very temporary
20:31:08 <arunkant> woodster_, the reason is..asking for a role in given project..means somebody has to do that assignment first..in that case just assign the needed role (instead of dummy one)..so its kind of defeats the purpose of ACL
20:31:56 <rm_work> arunkant: again, I assume it's ONE role assignment, not per project but for the user's own project
20:32:10 <woodster_> arunkant, you are thinking that if a user is no longer able to access barbican, they should just be removed from ACL lists then? That requires knowledge of barbican API to disable that user though, whereas role revocation is something an admin can do without knowledge of barbican beyond its roles.
20:32:32 <rm_work> so I have ONE "read_other" role assigned to me, for my own project -- which is checked when I try to read someone else's secret that I'm whitelisted for
20:32:48 <rm_work> and that is granted by default to every barbican user
20:32:53 <rm_work> but could be removed manually
20:33:06 <woodster_> arunkant, if you are concerned about clean up of ACLs when users are removed from identity, the keystone listener service could handle that
20:33:12 <rm_work> (again, just talking about DEFAULT deployment -- it's always up to the provider)
20:34:17 <rm_work> I thought we had a good set of logic worked out for this in one of the specs? which indicated an additional role, as we're discussing now
20:35:13 <redrobot> rm_work I'm coming around to having a new role...  or maybe two?  "secret_acl" and "container_acl" ?
20:35:20 <arunkant> woodster_, clean up of ACLs is not my concern..its just a role assignment part..now every cloud user need to have a role assignment.
20:35:36 <rm_work> redrobot: possibly -- it may or may not matter -- up to the deployer
20:35:50 <rm_work> redrobot: in a simple configuration, just one would probably be fine (for a default install)
20:36:15 <rm_work> I remember arguing against checking the existing "read" role, for similar reasons as above
20:36:37 <rm_work> (not adding additional functionality to an existing role that wasn't originally intended)
20:36:50 <rm_work> but we came to a consensus before than a new role would be ok, I swear
20:36:51 <woodster_> so I guess we'll have a 'default' out of the box policy config, and then the deployer guide could detail other options?
20:37:30 <redrobot> arunkant only if a deployer uses the default policy.   Plus, you could configure your user provisioning system to add the role automatically, so I don't see it as a burden.
20:38:00 <redrobot> woodster_ +1
20:38:35 <elmiko> always +1 to better docs ;)
20:39:27 <redrobot> It seems most of us are in favor of adding a new role to the default policy
20:39:27 <arunkant> redrobot: Yes. That should be okay. +1
20:39:34 <woodster_> arunkant, my concern is more the more intimate knowledge cloud admins will need of barbican to disable users from barbican only...I'd favor a default policy that requires a roles, with a more relaxed one for as an alternate described in teh deployers guide
20:40:01 <redrobot> arunkant awesome, that settles it then
20:40:07 <woodster_> +1 redrobot. So to bike shed on the name of this new role....
20:40:27 <redrobot> #agreed we'll add a new role to be used in combination with per-secret policy in the default policy file
20:40:38 <redrobot> hehe, bikeshedding indeed
20:40:47 <redrobot> I propose the role: "barbican_acl"
20:40:52 <woodster_> 'read-granted' maybe?
20:41:16 <redrobot> I think barbican_acl describes that the access list is owned by barbican
20:41:27 <woodster_> this role would be ignored unless the secret has ACL applied, correct?
20:41:35 <arunkant> are acls intended to be only for read? I thought for future..the plan was for other operations as well
20:41:35 <redrobot> yep
20:42:07 <redrobot> arunkant good point.  I think "barbican_acl" would not need to change if we decide to add other operations down the line
20:43:16 <woodster_> The other roles are nouns though...barbican-acler? :)
20:43:42 <elmiko> hehe
20:43:52 <redrobot> acl (access control list) is a noun
20:44:44 * redrobot is tired of bikeshedding and wants to move on to more important things
20:44:51 <woodster_> they are adjectives that is...he is a creator, etc...
20:45:01 <redrobot> we can bikeshed the name on the CR
20:45:09 <woodster_> we can pick that up in the IRC channle
20:45:15 <redrobot> #topic Kilo bugs
20:45:16 <woodster_> redrobot +1
20:46:05 <redrobot> Thanks to dave-mccowan working over the weekend we now have a set of functional tests that exercise the workflows we discussed on Friday
20:46:46 <woodster_> dave-mccowan: nice!
20:46:46 <redrobot> #link https://review.openstack.org/#/c/172401/
20:47:14 <redrobot> note that a lot of tests are currently skipped pending bugfixes
20:47:25 <redrobot> so, we need some bug squashers in the next couple of days
20:47:27 <redrobot> #link https://bugs.launchpad.net/barbican
20:47:40 <redrobot> if you want to squash a bug, just assign it to yourself.
20:47:56 <redrobot> that way other contributors know that someone is working on it
20:48:21 <alee_> redrobot, when is the deadline for rc1?
20:48:24 <jaosorior> redrobot: redrobot are the bugs already reported?
20:48:51 <redrobot> alee_ preferably in the next few days
20:48:51 <dave-mccowan> #link https://etherpad.openstack.org/p/barbican-rsa-key-tests
20:49:03 <rm_work> woodster_: BTW if the thing you were working on was a bugfix for RC1, you should not wait on me -- I doubt I'll get my devstack updates fixed and ready to go before Kilo is officially donezo
20:49:06 <redrobot> alee_ most of the integrated projects have already released the RC
20:49:20 <redrobot> jaosorior I think so, but dave-mccowan can correct me if I'm wrong
20:49:50 <alee_> redrobot, right -- so can we have all the relevant bugs assigned by end of today or earliest early tommorow then
20:51:46 <redrobot> I'm currently working on validation fixes for https://bugs.launchpad.net/barbican/+bug/1441866
20:51:47 <openstack> Launchpad bug 1441866 in Barbican "public type secret creation fails with 400" [Critical,Confirmed] - Assigned to Douglas Mendizábal (dougmendizabal)
20:52:37 <dave-mccowan> redrobot, do you expect your fix to that will close any of the other open bugs?
20:52:59 <redrobot> dave-mccowan not sure yet... but hopefully yes.
20:54:01 <redrobot> alrighty... any last minute topics we want to cover?
20:54:24 <arunkant> is there plan to add support for ACLs in barbican client?
20:54:48 <redrobot> arunkant I think we would like the client to support everything that Barbican does
20:55:02 <redrobot> arunkant so if you want to implement ACLs in the client, please do so
20:55:14 <woodster_> ohhh, and docs too
20:55:28 <arunkant> okay. will look into that. yes docs as well.
20:55:39 <jaosorior> arunkant: thought that would be included in the ACL blueprint work. The client should support the API entirely
20:56:55 <jaosorior> Which reminds me. The client is not functional at the moment
20:56:59 <rm_work> erk
20:57:02 <arunkant> yes..was just trying to find out if anybody else is working on barbican client side?
20:57:18 <rm_work> usually I am able to help out with client stuff -- MIGHT be able to fit that in soon
20:57:24 <rm_work> if no one else has time
20:57:33 <dave-mccowan> one kilo bug question from this review: https://review.openstack.org/172819
20:57:39 <jaosorior> Anybody has time to check this one?  https://review.openstack.org/#/c/172958/
20:58:02 <dave-mccowan> should the server reject an order that includes meta['payload'] when that field is not used?
20:58:20 <redrobot> eek 2 min left
20:58:20 <jaosorior> That fixes the... non-functionalness
20:58:42 <redrobot> dave-mccowan maybe?  does including random meta['foo'] fail?
20:58:43 <rm_work> yeah i reviewed that earlier, meant to +1
20:59:08 <dave-mccowan> redrobot, no.  post answers to review.
20:59:19 <redrobot> dave-mccowan will do
20:59:22 <redrobot> thanks for coming everyone
20:59:28 <redrobot> #endmeeting