20:00:30 <redrobot> #startmeeting barbican
20:00:31 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:34 <openstack> The meeting name has been set to 'barbican'
20:00:42 <redrobot> #topic Roll Call
20:00:47 <jmckind> o/
20:00:49 <edtubill> o/
20:00:52 <mp1> o /
20:01:04 <woodster_> o/
20:01:14 <redrobot> As usual the agenda can be found here:
20:01:15 <redrobot> #link https://wiki.openstack.org/wiki/Meetings/Barbican#Agenda
20:02:41 <arunkant> o/
20:02:51 <kfarr> o/
20:03:33 <redrobot> Not a whole lot of barbicaneers here today
20:03:45 <redrobot> #topic Design Summit
20:04:06 <redrobot> #link https://etherpad.openstack.org/p/newton-barbican-design-sessions
20:04:12 <redrobot> The design summit is next week.
20:04:21 <redrobot> Looking forward to seeing everyone in Ausin!
20:04:26 <redrobot> *Austin
20:04:50 <redrobot> I added the Barbican schedule to the etherpad
20:04:55 <redrobot> Thursday is going to be a long day
20:05:06 <redrobot> also godo news arunkant we did get the 1/2 day meetup on Friday morning.
20:05:12 <redrobot> *good
20:05:17 * redrobot can't type today
20:05:25 <arunkant> redrobot: just noticed that..great
20:05:37 <panatl> o/
20:06:06 <redrobot> It appears there was some miscommunication with the Security folks, since they also have a BYOK fishbowl
20:06:43 <redrobot> Thinking we can go to their fishbowl on Wednesday and then continue the conversation during our fishbowl.
20:07:02 <redrobot> not sure that we'll have 2 fishbowls worth of things to discuss though...
20:07:30 <redrobot> any questions/comments about the summit?
20:07:39 <arunkant> redrobot: what is the agenda for other wednesday sessions. I see byok on afternoon
20:08:20 <redrobot> arunkant for the regular (non-fishbowls) sessions we'll be going through the etherpad like previous summits.
20:08:31 <arunkant> redrobot: okay
20:08:51 <redrobot> ok, moving on
20:09:36 <redrobot> #topic Bugfix Backports
20:09:57 <redrobot> let's do these one at a time:
20:10:01 <redrobot> #link https://review.openstack.org/#/c/303648/
20:11:15 <arunkant> panatl has these changes related to sql password and token printed in logs in debug
20:11:46 <redrobot> 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 <redrobot> Liberty backport:
20:12:12 <redrobot> #link https://review.openstack.org/#/c/303845/
20:12:12 <panatl> 303648 . ia all done i guess
20:12:20 <redrobot> Mitaka backport:
20:12:26 <redrobot> #link https://review.openstack.org/#/c/304335/
20:13:06 <panatl> redroot: it is a security concerns .. so nee to patch both Liberty and mitaka
20:13:46 <redrobot> panatl I understand it's a security concern, but it's not a critical issue
20:13:51 <panatl> we talked seperatly on that .. and u said just rephrase statement and avoid secret in logs
20:14:10 <redrobot> I imagine most people won't ever run production environments in debug mode
20:14:30 <redrobot> panatl I think it's a good fix
20:14:35 <panatl> thanks
20:14:40 <redrobot> just not critical enough to re-release Mitaka and Liberty
20:15:02 <arunkant> 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 <panatl> barbican is about security ... i think this is critical.. need to protect sensitive informaiton :)
20:16:11 <panatl> +1 to arunkant:
20:17:07 <redrobot> panatl by not critical, I mean this is a Class B3 vuln https://security.openstack.org/vmt-process.html#publish-ossa
20:17:28 <redrobot> panatl we could just issue a OSSN and not have to re-release Mitaka and Liberty
20:17:59 <redrobot> panatl so not a Class A vulnerability
20:18:20 <panatl> ok ... we should atleast do the mitaka
20:18:49 <redrobot> panatl I think we can fix in master and write up OSSNs for Mitaka and Liberty
20:19:06 <redrobot> panatl mitaka was just released, and I don't think this level of vulnerability merits a re-release of mitaka either.
20:19:55 <panatl> ok thanks
20:20:28 <redrobot> panatl do you want to write the OSSN?
20:20:52 <panatl> sure ... never done that.. but like to get involved
20:20:58 <redrobot> panatl cool
20:21:39 <redrobot> #action panatl to write OSSN for Mitaka and Liberty regarding Bug #1567500
20:21:41 <openstack> 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 <edtubill> n
20:22:20 <edtubill> finger slipped. ignore that.
20:22:55 <redrobot> I think that covers the backports?
20:23:02 <redrobot> I just noticed the first link was not a backport patch
20:23:23 <panatl> yes that coveres BP
20:23:31 <arunkant> redrobot: does this merit a backport https://review.openstack.org/#/c/303648/  .
20:24:14 <arunkant> redrobot: It a critical error logged if client sends json-home header to http://localhost:9311/v1 call.
20:24:36 <redrobot> arunkant critical log?  as in a 500 happens?
20:25:09 <arunkant> Yes..it reports error on client side and then log 'CRITICA' level log in barbican log
20:26:29 <redrobot> arunkant if the service returns a 500 instead of a 406 Not Acceptable, then we should backport it
20:26:46 <redrobot> arunkant but if the issue is just an incorrect log level, then I don't think it's critical.
20:28:24 <arunkant> redrobot: It does not return 406..it returns error . Change is to handle the issue correctly..so no 406 is returned
20:29:07 <redrobot> > returns error ?  does that mean 500 response?
20:29:36 * redrobot is confused because bot 4XX and 5XX responses are errors
20:30:44 <arunkant> redrobot : It returns "Internal server error" ..see the trace ..https://bugs.launchpad.net/barbican/+bug/1568141
20:30:46 <openstack> 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 <arunkant> redrobot: So yes 500 error
20:31:16 <redrobot> arunkant yeah, I think that should be backported to Mitaka then
20:31:31 <redrobot> arunkant and/or liberty if it's also affected
20:31:57 <arunkant> redrobot: Okay..I will add the patch for both of branches
20:32:03 <redrobot> arunkant awesome, thanks
20:32:33 <redrobot> ok, moving on
20:32:39 <redrobot> #topic  Should creator be allowed to delete related barbican resources?
20:33:31 <redrobot> #info No, "creator" should not be allowed to delete resources
20:33:42 <arunkant> 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 <redrobot> arunkant that is expected
20:34:20 <redrobot> the only difference between admin and creator is that admin can delete and creator cannot
20:34:20 <arunkant> redrobot: the reason is for deleting the key, they require admin role ..
20:34:30 <redrobot> arunkant yes, that is by design
20:34:58 <arunkant> redrobot: why is that ? I mean from client perspective, which role they should be assigned ..creator or admin ..
20:35:22 <redrobot> arunkant from a client perspective, the client should have at least one user with the "admin" role on their tenant
20:35:31 <redrobot> arunkant that user can add/delete secrets within that tenant
20:35:52 <redrobot> "creator" was added as a role that can guarantee that secrets can't be deleted
20:36:18 <arunkant> 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 <redrobot> "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 <redrobot> arunkant cinder roles != barbican roles
20:37:19 <arunkant> 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 <arunkant> 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 <redrobot> I'm not super knowledgeable about the cinder workflow, maybe kfarr can chime in...
20:38:27 <redrobot> arunkant "work it properly"?
20:38:55 <redrobot> as I was saying, the only difference between admin and creator is that creator cannot delete
20:39:12 <redrobot> if we let creator also delete, then there is no difference between the "admin" role and the "creator" role
20:39:23 <redrobot> so what would be the point of defining two roles with the same set of permissions?
20:39:26 <arunkant> 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 <redrobot> arunkant cinder workflow aside, why do you want two roles with the same permissions?
20:40:39 <redrobot> arunkant is this a problem in a devstack integration test between cinder and barbican?
20:40:47 <arunkant> 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 <arunkant> 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 <redrobot> arunkant because secrets are scoped to projects
20:42:23 <kfarr> 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 <redrobot> arunkant all RBAC has been designed around the tenant roles
20:43:04 <arunkant> 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 <kfarr> * to delete the keys
20:43:26 <redrobot> 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 <woodster_> 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 <arunkant> woodster_ : yes..similar to that...add creator role to allow that .
20:45:31 <redrobot> arunkant It sounds to me like you're wanting to add policy around user-identity as well as role-within-tenant
20:46:03 <woodster_> cinder doesn't appear to care much about roles it seems. It seems Barbican should be more stringent than that
20:46:28 <redrobot> woodster_ +1
20:46:30 <arunkant> redrobot: I am asking if it make sense to make change in master as this is a cinder use case..
20:47:21 <arunkant> 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 <redrobot> arunkant yes, because you need the barbican admin role to be able to delete secrets
20:48:29 <arunkant> 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 <woodster_> 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 <redrobot> 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 <redrobot> arunkant is it just a naming issue?
20:49:56 <redrobot> arunkant does cinder have a "creator" role?
20:50:03 <woodster_> I think by 'creator' it is in the cinder context, so really the user who created the secret
20:50:16 <woodster_> ...not 'creator' in the barbican roles sense
20:50:55 <arunkant> 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 <redrobot> arunkant understood, we can revisit this if you can identify how creator+delete would be different than admin
20:52:26 <arunkant> 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 <woodster_> it would be good to get the security group's opinion about these things too
20:53:16 <woodster_> arunkant: my read is that no role is needed at all, but not sure how their middleware is connected
20:53:34 <redrobot> woodster_ I think you made a good point about having more narrowly scoped roles within devstack
20:53:47 <redrobot> woodster_ I think there's a cross-project meeting to that effect
20:54:22 <woodster_> 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 <arunkant> redrobot: If we allow creator user (user who created the secret) to delete secret, will that be okay. S
20:56:00 <redrobot> 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 <arunkant> 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 <woodster_> 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 <woodster_> ...so perhaps with no role on the project
20:57:57 <redrobot> I guess we'd be expanding the ownership of the secret to one user (the one who uploaded the secret) + project ...
20:58:03 <arunkant> 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 <redrobot> it complicates the RBAC matrix a bit
20:58:26 <redrobot> ... aaand we're almost out of time
20:58:41 <woodster_> arunkant: it seems cinder's ask is to not have any role for this create/delete flow
20:58:42 <arunkant> redrobot: yes..but it can handle cinder use case.
20:58:42 <redrobot> interesting conversation though... we should add it to the etherpad for things to discuss in Austin.
20:59:32 <woodster_> maybe hockeynut could bring cinnamon roles for that discussion like at the midcycle a while back
20:59:36 <redrobot> no IRC meeting next week because Summit.
21:00:12 <redrobot> #endmeeting