20:00:30 #startmeeting barbican 20:00:31 Meeting started Mon Apr 18 20:00:30 2016 UTC and is due to finish in 60 minutes. The chair is redrobot. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00:32 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:00:34 The meeting name has been set to 'barbican' 20:00:42 #topic Roll Call 20:00:47 o/ 20:00:49 o/ 20:00:52 o / 20:01:04 o/ 20:01:14 As usual the agenda can be found here: 20:01:15 #link https://wiki.openstack.org/wiki/Meetings/Barbican#Agenda 20:02:41 o/ 20:02:51 o/ 20:03:33 Not a whole lot of barbicaneers here today 20:03:45 #topic Design Summit 20:04:06 #link https://etherpad.openstack.org/p/newton-barbican-design-sessions 20:04:12 The design summit is next week. 20:04:21 Looking forward to seeing everyone in Ausin! 20:04:26 *Austin 20:04:50 I added the Barbican schedule to the etherpad 20:04:55 Thursday is going to be a long day 20:05:06 also godo news arunkant we did get the 1/2 day meetup on Friday morning. 20:05:12 *good 20:05:17 * redrobot can't type today 20:05:25 redrobot: just noticed that..great 20:05:37 o/ 20:06:06 It appears there was some miscommunication with the Security folks, since they also have a BYOK fishbowl 20:06:43 Thinking we can go to their fishbowl on Wednesday and then continue the conversation during our fishbowl. 20:07:02 not sure that we'll have 2 fishbowls worth of things to discuss though... 20:07:30 any questions/comments about the summit? 20:07:39 redrobot: what is the agenda for other wednesday sessions. I see byok on afternoon 20:08:20 arunkant for the regular (non-fishbowls) sessions we'll be going through the etherpad like previous summits. 20:08:31 redrobot: okay 20:08:51 ok, moving on 20:09:36 #topic Bugfix Backports 20:09:57 let's do these one at a time: 20:10:01 #link https://review.openstack.org/#/c/303648/ 20:11:15 panatl has these changes related to sql password and token printed in logs in debug 20:11:46 I don't think fixing a debug statement merits spinning up a new release of barbican 20:11:59 * redrobot realizes that's the other bug 20:12:11 Liberty backport: 20:12:12 #link https://review.openstack.org/#/c/303845/ 20:12:12 303648 . ia all done i guess 20:12:20 Mitaka backport: 20:12:26 #link https://review.openstack.org/#/c/304335/ 20:13:06 redroot: it is a security concerns .. so nee to patch both Liberty and mitaka 20:13:46 panatl I understand it's a security concern, but it's not a critical issue 20:13:51 we talked seperatly on that .. and u said just rephrase statement and avoid secret in logs 20:14:10 I imagine most people won't ever run production environments in debug mode 20:14:30 panatl I think it's a good fix 20:14:35 thanks 20:14:40 just not critical enough to re-release Mitaka and Liberty 20:15:02 redrobot: Yes..but if somebody just runs barbican in debug logs for debugging perspective, they will be able to see other people's token . 20:15:47 barbican is about security ... i think this is critical.. need to protect sensitive informaiton :) 20:16:11 +1 to arunkant: 20:17:07 panatl by not critical, I mean this is a Class B3 vuln https://security.openstack.org/vmt-process.html#publish-ossa 20:17:28 panatl we could just issue a OSSN and not have to re-release Mitaka and Liberty 20:17:59 panatl so not a Class A vulnerability 20:18:20 ok ... we should atleast do the mitaka 20:18:49 panatl I think we can fix in master and write up OSSNs for Mitaka and Liberty 20:19:06 panatl mitaka was just released, and I don't think this level of vulnerability merits a re-release of mitaka either. 20:19:55 ok thanks 20:20:28 panatl do you want to write the OSSN? 20:20:52 sure ... never done that.. but like to get involved 20:20:58 panatl cool 20:21:39 #action panatl to write OSSN for Mitaka and Liberty regarding Bug #1567500 20:21:41 bug 1567500 in Barbican "Barbican server discloses SQL Connection String containing a Password via LOG.debug()" [Low,Fix released] https://launchpad.net/bugs/1567500 - Assigned to Pankaj Khandar (pankaj-khandar) 20:21:44 n 20:22:20 finger slipped. ignore that. 20:22:55 I think that covers the backports? 20:23:02 I just noticed the first link was not a backport patch 20:23:23 yes that coveres BP 20:23:31 redrobot: does this merit a backport https://review.openstack.org/#/c/303648/ . 20:24:14 redrobot: It a critical error logged if client sends json-home header to http://localhost:9311/v1 call. 20:24:36 arunkant critical log? as in a 500 happens? 20:25:09 Yes..it reports error on client side and then log 'CRITICA' level log in barbican log 20:26:29 arunkant if the service returns a 500 instead of a 406 Not Acceptable, then we should backport it 20:26:46 arunkant but if the issue is just an incorrect log level, then I don't think it's critical. 20:28:24 redrobot: It does not return 406..it returns error . Change is to handle the issue correctly..so no 406 is returned 20:29:07 > returns error ? does that mean 500 response? 20:29:36 * redrobot is confused because bot 4XX and 5XX responses are errors 20:30:44 redrobot : It returns "Internal server error" ..see the trace ..https://bugs.launchpad.net/barbican/+bug/1568141 20:30:46 Launchpad bug 1568141 in Barbican "Unhandled CRITICAL error raised for json-home request to /v1 resource" [Medium,Fix released] - Assigned to Arun Kant (arunkant-uws) 20:30:59 redrobot: So yes 500 error 20:31:16 arunkant yeah, I think that should be backported to Mitaka then 20:31:31 arunkant and/or liberty if it's also affected 20:31:57 redrobot: Okay..I will add the patch for both of branches 20:32:03 arunkant awesome, thanks 20:32:33 ok, moving on 20:32:39 #topic Should creator be allowed to delete related barbican resources? 20:33:31 #info No, "creator" should not be allowed to delete resources 20:33:42 redrobot: this is the case we observed when people are using cinder envrypted volumes. We ask them to use creator role for creating keys..but then when user deletes the volume, it failed with 403 error on barbican side 20:34:05 arunkant that is expected 20:34:20 the only difference between admin and creator is that admin can delete and creator cannot 20:34:20 redrobot: the reason is for deleting the key, they require admin role .. 20:34:30 arunkant yes, that is by design 20:34:58 redrobot: why is that ? I mean from client perspective, which role they should be assigned ..creator or admin .. 20:35:22 arunkant from a client perspective, the client should have at least one user with the "admin" role on their tenant 20:35:31 arunkant that user can add/delete secrets within that tenant 20:35:52 "creator" was added as a role that can guarantee that secrets can't be deleted 20:36:18 redrobot: But cinder allows creation of volume to any user with *any* role in a tenant.. https://github.com/openstack/cinder/blob/master/etc/cinder/policy.json#L9 20:36:20 "creator" is intended for automation systems that create keys for example. It helps guarantee that such a system can't run amok and delete a bunch of secrets 20:36:40 arunkant cinder roles != barbican roles 20:37:19 redrobot: Yes..but then if user is using cinder volumes..do they all be assigned 'admin' role as cinder does allow user to delete volume 20:38:12 I meant barbican 'admin' role. I think it defeats the purpose if every used needs barbican admin role to work it properly. 20:38:12 I'm not super knowledgeable about the cinder workflow, maybe kfarr can chime in... 20:38:27 arunkant "work it properly"? 20:38:55 as I was saying, the only difference between admin and creator is that creator cannot delete 20:39:12 if we let creator also delete, then there is no difference between the "admin" role and the "creator" role 20:39:23 so what would be the point of defining two roles with the same set of permissions? 20:39:26 redrobot: In horizon, a user can create cinder volume and can delete that volume for that tenant. If they use encrypted volumes, then they need admin role to do both 20:40:13 arunkant cinder workflow aside, why do you want two roles with the same permissions? 20:40:39 arunkant is this a problem in a devstack integration test between cinder and barbican? 20:40:47 redrobot: creator role is not sufficient alone. Or may be we change barbican policy such that user with creator role who created the secret can delete it. 20:41:51 redrobot: No this is a actual deployment with cinder and barbican. I am trying to see the reason why we don't allow user who created the secret ..is allowed to delete it 20:42:10 arunkant because secrets are scoped to projects 20:42:23 just chiming in that arunkant is right, a non-admin cinder user can create volumes, but needs to have barbican admin role assigned in order to create the keys necessary for encrypted volumes 20:42:24 arunkant all RBAC has been designed around the tenant roles 20:43:04 redrobot: We capture creator id in secrets..so we can easily limit access to user with creator role and matching that token user id == secret.creator_id 20:43:06 * to delete the keys 20:43:26 arunkant you can re-write your policy to fit your use case... I thought we were talking about changing the default policy file that is used in devstack 20:43:28 arunkant: so are you asking that there be an 'or' clause for the secret's user on this line (for example)?: https://github.com/openstack/barbican/blob/master/etc/barbican/policy.json#L33 20:45:28 woodster_ : yes..similar to that...add creator role to allow that . 20:45:31 arunkant It sounds to me like you're wanting to add policy around user-identity as well as role-within-tenant 20:46:03 cinder doesn't appear to care much about roles it seems. It seems Barbican should be more stringent than that 20:46:28 woodster_ +1 20:46:30 redrobot: I am asking if it make sense to make change in master as this is a cinder use case.. 20:47:21 woodster_ : Yes, stringent is fine..but then what we are saying to user who wants to use encrypted volume, they have barbican admin role .. 20:47:46 arunkant yes, because you need the barbican admin role to be able to delete secrets 20:48:29 woodster_ : And as cinder allows every user to have encrpyted volume..that means all users needs to have barbican admin role..which defeats the purpose of admin vs creator on barbican side. 20:48:51 well, I think there is a desire to simplify openstack configuration in general, so I would presume that means out of the box configs being fit to purpose. But that could also mean that we should be adding role usage where it hasn't been used, in the name of enhanced security. Seems design session/cross-project ish to me :) 20:49:20 arunkant again, you never answered my question: If the only difference between admin and creator is that creator cannot delete, then if we add delete capabilities to creator what is the difference between the two? 20:49:25 arunkant is it just a naming issue? 20:49:56 arunkant does cinder have a "creator" role? 20:50:03 I think by 'creator' it is in the cinder context, so really the user who created the secret 20:50:16 ...not 'creator' in the barbican roles sense 20:50:55 redrobot: May be there are other differences..will need to check it. But from client usage perspective, as I said all users wil need to have admin role if they want to work with encrypted volumes 20:51:13 * woodster_ though this Cinder policy line refers to a project match, not user ID match, correct?: "admin_or_owner": "is_admin:True or project_id:%(project_id)s", 20:51:32 arunkant understood, we can revisit this if you can identify how creator+delete would be different than admin 20:52:26 woodster_ : Yes , I am surprised as well as cinder allows access to most of its resource with just any role on that tenant 20:52:31 it would be good to get the security group's opinion about these things too 20:53:16 arunkant: my read is that no role is needed at all, but not sure how their middleware is connected 20:53:34 woodster_ I think you made a good point about having more narrowly scoped roles within devstack 20:53:47 woodster_ I think there's a cross-project meeting to that effect 20:54:22 well, my overall point is to balance ease of integration/adoption of barbican, with appropriate security constraints...some sort of happy medium in there perhaps 20:55:19 redrobot: If we allow creator user (user who created the secret) to delete secret, will that be okay. S 20:56:00 arunkant my point was that if we do that, then there would be no difference between a creator and an admin. The only difference would be the role name. 20:56:18 redrobot: So it means that other users with creator role in same project..cannot delete other user's secrets..only their own 20:57:00 I think the 'creator' role is the red herring here...I think we are really talking about the user who created the secret 20:57:11 ...so perhaps with no role on the project 20:57:57 I guess we'd be expanding the ownership of the secret to one user (the one who uploaded the secret) + project ... 20:58:03 woodster_ , creator or admin can only create entities..so that's why was using creator role..but yes essentially its the user who created the secret at first place. 20:58:13 it complicates the RBAC matrix a bit 20:58:26 ... aaand we're almost out of time 20:58:41 arunkant: it seems cinder's ask is to not have any role for this create/delete flow 20:58:42 redrobot: yes..but it can handle cinder use case. 20:58:42 interesting conversation though... we should add it to the etherpad for things to discuss in Austin. 20:59:32 maybe hockeynut could bring cinnamon roles for that discussion like at the midcycle a while back 20:59:36 no IRC meeting next week because Summit. 21:00:12 #endmeeting