19:59:56 #startmeeting barbican 19:59:57 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:00:00 The meeting name has been set to 'barbican' 20:00:00 o/ 20:00:05 o/ 20:00:10 o/ 20:00:16 yo/ 20:01:37 not a whole lot of people here yet... 20:01:44 let's get started anyway 20:02:04 as usual the Agenda can be found here: 20:02:05 #link https://wiki.openstack.org/wiki/Meetings/Barbican 20:02:15 #topic Action Items 20:02:26 #link http://eavesdrop.openstack.org/meetings/barbican/2015/barbican.2015-04-06-20.00.html 20:02:44 so I totally dropped the ball and did not get to complete any of the action items I had last week 20:02:53 #action redrobot to figure out why Castellan 0.1.0 tag did not get published to PyPI 20:03:00 #action redrobot to email dev list to get input on minor changes in the API 20:03:30 elmiko do you want to give an update on the Juno to Kilo migration you tested? 20:03:37 o/ 20:03:42 sure thing 20:03:50 so i ran the migration tests 20:04:11 there were some issues regarding one of the statements 20:04:26 #link https://gist.github.com/elmiko/34c2f064c104d08a3e1f 20:04:30 if anyone is curious 20:04:53 ah o/ 20:04:55 i tried to start with a stable juno install, then run the db-migrate with a master code base 20:05:20 o/ 20:05:25 elmiko I wonder if this is specific to Maria DB or if it would affect MySQL as well? 20:05:34 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 redrobot: that's a great question 20:06:01 I tried the migration from Juno -> Master on PostgreSQL and it seems to have worked without issues. 20:06:01 i can do a setup with postgresql as well, if barbican supports that 20:06:11 hmm, maybe it's just maria 20:06:23 i'll put together a true mysql setup and run again 20:06:36 elmiko you're awesome! thanks. 20:06:51 #action elmiko to try Juno -> Kilo migration in MySQL 20:07:28 np, glad to help =) 20:07:41 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 k, maria is just the default for fedora 20:08:49 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 good call 20:09:23 #action redrobot to talk to Greg Swift about the DB used in the official Fedora RPM 20:10:09 ok, moving on 20:10:21 #topic Vancouver Design Summit 20:11:30 #link http://lists.openstack.org/pipermail/openstack-dev/2015-April/061167.html 20:11:59 The tentative slot allocation for Vancouver is up 20:12:21 We're scheduled for 3 fishbowls and 10 regular sessions 20:12:34 what we've done in the past is vote on the design summit wiki page which we want sessions for 20:12:50 #link https://etherpad.openstack.org/p/barbican-L-design-sessions 20:13:05 we've also got a half day on Friday 20:13:09 thanks woodster_ 20:13:09 o/ 20:13:21 it would be good to figure out if we will indeed need 3 fishbowl sessions 20:13:49 as a reminder, Fishbowl means it's a session that is listed on the scheduled where wide community input is needed 20:14:20 the regular sessions are table discussion times then? 20:14:26 woodster_ yes 20:15:09 which means we may end up with some time slots where we don't have a room :-\ 20:15:44 that's why they invented hallways 20:15:46 So, everyone please take a look at the etherpad that woodster_ linked. 20:15:50 rolling whiteboards? 20:15:58 I'd like to know if we do need all 3 fishbowls soon 20:16:13 It would be nice to give back fishbowls we may not need 20:17:29 woodster_ who knows... 20:17:36 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 woodster_ would be good to figure it out this week 20:18:19 Yeah, please add +1s to topics you want to discuss in the summit 20:18:24 so vote by COB Wednesday maybe? 20:18:39 woodster_ yep, that sounds like a plan 20:19:20 also add (Fishbowl) to sessions you think may need wide community input 20:19:44 and by "you" I mean all you wonderful Barbicaneers :) 20:20:11 any questions/comments about Design Summit planning? 20:21:13 ok, moving on 20:21:26 #topic Additional Role for per-secret ACL 20:22:09 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 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 which does work, but it does not allow for an easy way to turn off access to Barbican for a user 20:23:48 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 one suggestion was to add a new role that is checked in addition to the ACL list 20:24:12 cannot we remove that user from ACL list to remove access ? 20:24:16 rm_work, I recall you mentioning a 'read-only-reader' sort of role 20:24:27 yeah, I thought that was the decision 20:24:30 previously 20:24:35 another option was to reuse the "audit" role 20:24:42 so, require "audit" role + ACL 20:24:44 redrobot: in general i am against role-reuse 20:25:11 roles in this sense need to be the most fine-grained units possible 20:25:29 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 tacking things on to other things is sketchy for security <_< 20:25:32 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 rm_work why? 20:25:48 rm_work why are you opposed to saying that ACL requires Audit role? 20:26:00 redrobot: because why not make a "read_other" role? 20:26:12 why tack on additional unrelated functionality to a role designed for *auditing*? 20:26:26 +1, that makes sense to me 20:26:57 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 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 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 redrobot: as long as it's a NEW role 20:27:30 that's what i'm saying :P 20:27:32 I've been viewing things as roles first, then ACL to narrow down access 20:27:38 name doesn't matter, just don't tie it to an existing role <_< 20:27:48 which was originally intended for a different purpose 20:28:07 rm_work: +1 20:28:26 I should also point out that this only affects the default policy we include with barbican 20:28:33 deployers are free do to whatever they please 20:28:40 true, i have echoed that before as well 20:28:42 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 this is all just deployer policy 20:29:25 woodster_, cannot we just add API to remove per project ACLs ? 20:29:31 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 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 so if i'm user1234, then read_other:user1234 && whitelisted 20:30:27 arunkant: and that is really messy for things like *suspensions* 20:30:37 where it might be very temporary 20:31:08 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 arunkant: again, I assume it's ONE role assignment, not per project but for the user's own project 20:32:10 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 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 and that is granted by default to every barbican user 20:32:53 but could be removed manually 20:33:06 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 (again, just talking about DEFAULT deployment -- it's always up to the provider) 20:34:17 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 rm_work I'm coming around to having a new role... or maybe two? "secret_acl" and "container_acl" ? 20:35:20 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 redrobot: possibly -- it may or may not matter -- up to the deployer 20:35:50 redrobot: in a simple configuration, just one would probably be fine (for a default install) 20:36:15 I remember arguing against checking the existing "read" role, for similar reasons as above 20:36:37 (not adding additional functionality to an existing role that wasn't originally intended) 20:36:50 but we came to a consensus before than a new role would be ok, I swear 20:36:51 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 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 woodster_ +1 20:38:35 always +1 to better docs ;) 20:39:27 It seems most of us are in favor of adding a new role to the default policy 20:39:27 redrobot: Yes. That should be okay. +1 20:39:34 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 arunkant awesome, that settles it then 20:40:07 +1 redrobot. So to bike shed on the name of this new role.... 20:40:27 #agreed we'll add a new role to be used in combination with per-secret policy in the default policy file 20:40:38 hehe, bikeshedding indeed 20:40:47 I propose the role: "barbican_acl" 20:40:52 'read-granted' maybe? 20:41:16 I think barbican_acl describes that the access list is owned by barbican 20:41:27 this role would be ignored unless the secret has ACL applied, correct? 20:41:35 are acls intended to be only for read? I thought for future..the plan was for other operations as well 20:41:35 yep 20:42:07 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 The other roles are nouns though...barbican-acler? :) 20:43:42 hehe 20:43:52 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 they are adjectives that is...he is a creator, etc... 20:45:01 we can bikeshed the name on the CR 20:45:09 we can pick that up in the IRC channle 20:45:15 #topic Kilo bugs 20:45:16 redrobot +1 20:46:05 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 dave-mccowan: nice! 20:46:46 #link https://review.openstack.org/#/c/172401/ 20:47:14 note that a lot of tests are currently skipped pending bugfixes 20:47:25 so, we need some bug squashers in the next couple of days 20:47:27 #link https://bugs.launchpad.net/barbican 20:47:40 if you want to squash a bug, just assign it to yourself. 20:47:56 that way other contributors know that someone is working on it 20:48:21 redrobot, when is the deadline for rc1? 20:48:24 redrobot: redrobot are the bugs already reported? 20:48:51 alee_ preferably in the next few days 20:48:51 #link https://etherpad.openstack.org/p/barbican-rsa-key-tests 20:49:03 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 alee_ most of the integrated projects have already released the RC 20:49:20 jaosorior I think so, but dave-mccowan can correct me if I'm wrong 20:49:50 redrobot, right -- so can we have all the relevant bugs assigned by end of today or earliest early tommorow then 20:51:46 I'm currently working on validation fixes for https://bugs.launchpad.net/barbican/+bug/1441866 20:51:47 Launchpad bug 1441866 in Barbican "public type secret creation fails with 400" [Critical,Confirmed] - Assigned to Douglas Mendizábal (dougmendizabal) 20:52:37 redrobot, do you expect your fix to that will close any of the other open bugs? 20:52:59 dave-mccowan not sure yet... but hopefully yes. 20:54:01 alrighty... any last minute topics we want to cover? 20:54:24 is there plan to add support for ACLs in barbican client? 20:54:48 arunkant I think we would like the client to support everything that Barbican does 20:55:02 arunkant so if you want to implement ACLs in the client, please do so 20:55:14 ohhh, and docs too 20:55:28 okay. will look into that. yes docs as well. 20:55:39 arunkant: thought that would be included in the ACL blueprint work. The client should support the API entirely 20:56:55 Which reminds me. The client is not functional at the moment 20:56:59 erk 20:57:02 yes..was just trying to find out if anybody else is working on barbican client side? 20:57:18 usually I am able to help out with client stuff -- MIGHT be able to fit that in soon 20:57:24 if no one else has time 20:57:33 one kilo bug question from this review: https://review.openstack.org/172819 20:57:39 Anybody has time to check this one? https://review.openstack.org/#/c/172958/ 20:58:02 should the server reject an order that includes meta['payload'] when that field is not used? 20:58:20 eek 2 min left 20:58:20 That fixes the... non-functionalness 20:58:42 dave-mccowan maybe? does including random meta['foo'] fail? 20:58:43 yeah i reviewed that earlier, meant to +1 20:59:08 redrobot, no. post answers to review. 20:59:19 dave-mccowan will do 20:59:22 thanks for coming everyone 20:59:28 #endmeeting