20:01:13 <redrobot> #startmeeting barbican
20:01:14 <openstack> Meeting started Mon Jan 26 20:01:13 2015 UTC and is due to finish in 60 minutes.  The chair is redrobot. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:17 <openstack> The meeting name has been set to 'barbican'
20:01:22 <redrobot> #topic Roll Call
20:01:27 <rellerreller> o/
20:01:29 <jvrbanac> o/
20:01:30 <elmiko> o/
20:01:31 <lisaclark2> o/
20:01:35 <arunkant> o/
20:01:36 <kfarr> o/
20:01:37 <dave-mccowan> o/
20:01:40 <rm_work> o/
20:01:40 <jaosorior> o/
20:01:43 <reaperhulk> o/
20:01:47 <tsv> o/
20:02:03 <tkelsey> o/
20:02:11 <redrobot> lots of barbicaneers here today!
20:02:16 <redrobot> good thing because we have a full agenda
20:02:21 <redrobot> which, as usual, can be found here:
20:02:27 <SheenaG1> o/
20:02:35 <redrobot> #link https://wiki.openstack.org/wiki/Meetings/Barbican
20:03:05 <hyakuhei> o/
20:03:24 <redrobot> ok, let's get this started
20:03:35 <redrobot> #topic KMIP MKEK
20:03:53 <redrobot> #link https://review.openstack.org/#/c/148948
20:03:54 <woodster_> o/
20:04:08 <hyakuhei> TL:DR; We thought we were building something similar to the p11 plugin for KMIP
20:04:08 <tkelsey> ok, so this is the spec #https://review.openstack.org/#/c/148948/
20:04:20 <tkelsey> ah redrobot got there before me :)
20:04:42 <tkelsey> so I would of course like input on the spec
20:04:51 <redrobot> ok, so I was looking over the spec earlier
20:04:56 <hyakuhei> Then there seems to be confusion about if this MKEK mode of behaviour can be conducted through the current KMIP Secret Store
20:05:22 <redrobot> yeah, I think there was some confusion on whether this would be new plugin or not
20:05:28 <rellerreller> I think there is also confusion over how this differs from the P11/HSM secret store
20:05:46 <hyakuhei> We see it as being a completely separate plugin to the current KMIP secret store
20:05:54 <hyakuhei> in no way a replacement, just a different approach
20:06:10 <jaosorior> hyakuhei: Basically I had initially thought that this would be a KMIPSecretStore v2, so I proposed to tkelsey that he should present it here.  But now it was cleared out that this will be a separate plugin
20:06:31 <hyakuhei> Clarification is always good
20:06:35 <rellerreller> +1 to different plugin than KMIPSecretStore
20:06:39 <tkelsey> I have updated the spec a moment ago to try and be more clear about thinks :)
20:06:42 <tkelsey> *things
20:06:51 <jaosorior> yeah, I gave the +2 to that spec, on the basis that this will be a separate plugin
20:06:59 <redrobot> rellerreller This new plugin would be different from P11/HSM in that it speaks KMIP to the appliance instead of PCKS#11
20:07:29 <hyakuhei> exactly
20:07:33 <rellerreller> Do we need a whole new plugin for that or just tweak the p11 plugin?
20:07:54 <hyakuhei> KMIP and P11 work very differently in places
20:07:56 <jaosorior> rellerreller: I think that would make things pretty confusing
20:08:09 <hyakuhei> and the kmip library doesn’t currently support the fancy features that p11 leverages
20:08:11 <tkelsey> jaosorior: +1
20:08:14 <hyakuhei> like in-HSM session keys
20:08:55 <rellerreller> I agree with that. I was wondering what the pain would be because most of the business logic sounds the same.
20:09:23 <rellerreller> For instance, create a MKEK then create a KEK for each project. Encrypt each key with a KEK.
20:09:58 <rellerreller> I was not sure how easy it would be to abstract talking to P11 or KMIP. If the answer is it's too much work then that is ok.
20:10:00 <hyakuhei> The p11 plugin is massive
20:10:03 <tkelsey> conceptually they are the same in that regard, I have updated the spec to reflect that, hopefully to make things clear to people
20:10:12 <rellerreller> Just wanted to raise the question because seem similar.
20:10:20 <hyakuhei> One day perhaps things could be abstracted away significantly
20:10:32 <hyakuhei> but the p11 plugin uses all of PKCS#11 functionality
20:10:41 <hyakuhei> Our KMIP one wont use all KMIP functionality
20:10:48 <hyakuhei> as most of it isn’t in the pykmip library yet
20:11:02 <jaosorior> rellerreller: I actually did suggest in the summit having some abstraction for the MKEK model, that could later be used. Such as in this case. But was told it was a very premature optimization :P
20:11:12 <hyakuhei> So the data flow and interaction will actually be different in a number of places
20:11:20 <redrobot> jaosorior maybe not premature anymore :)
20:11:52 <woodster_> hyakuhei: so will encrypt keys need to exist unencrypted outside hsm? I haven't looked at details yet
20:11:58 <jaosorior> I think we should have a couple of more plugins in there. And after seeing how that's working, I could submit a blueprint (if needed) for that
20:12:03 <hyakuhei> Look people. Stop bike shedding, we want to build $thing. $Thing doesn’t affect your $thing and consumers aren’t forced to use $thing. kthnxbye!
20:12:24 <hyakuhei> ^ is what I’d say in person if you could see my face and intonation
20:12:34 <redrobot> hyakuhei :)
20:12:36 <tkelsey> given the size (and my personal lack of familiarity with PKCS11) I would like to consider any factoring out of MKEK as a secondary activity after creating the new plugin
20:12:39 <jaosorior> kyakuhei: chillax
20:13:16 <hyakuhei> The model we’re proposing is sound and if you can build an abstraction layer for MKEK type operations and others then that’s awesome and I’ll commit now that we’d modify our plugin to work with that too (if required)
20:13:17 <jaosorior> Anyway, I think the plugin should go as is proposed at the moment. And we can think about refactoring later
20:13:29 <tkelsey> jaosorior: +1
20:13:31 <tkelsey> :)
20:13:48 <hyakuhei> but having spent some time looking at it, P11 and KMIP are quite different and there’s precious little reference implementations of KMIP
20:13:50 <redrobot> jaosorior +1 as well
20:14:11 <tkelsey> anyway I think its better to have to models of MKEK before trying to factor out comonality
20:14:19 <hyakuhei> +1
20:14:22 <jaosorior> tkelsey: exactly
20:14:50 <redrobot> I'll just point out that documentation should be clear in describing the differences between this KMIP MKEK plugin and the existing KMIP plugin.
20:15:08 <tkelsey> redrobot: agreed
20:15:16 <rellerreller> agreed
20:15:37 <tkelsey> if people think there is room to clarify the spec more in that regard then please drop feedback in gerrit
20:15:40 <jaosorior> Well, this will be something such as... KMIPMKEKSecretStore... should the other plugin be renamed to something that reflects the model it uses? so it becomes more apparent
20:15:43 <hyakuhei> +1 tkelsey do you think we can clarify more ?
20:15:58 <hyakuhei> and maybe stop calling the p11 plugin ‘HSM’ ?
20:16:14 <hyakuhei> As that is _super_ confusing for some of us :P
20:16:18 <tkelsey> hyakuhei: I can give it another pass, but take a look at the stuff I just put up as well
20:16:37 <redrobot> jaosorior I'm sure we'll get to bikeshed a name for the plugin class once the implementation is in review :)
20:16:39 <hyakuhei> cool, thanks.
20:17:02 <jaosorior> hyakuhei: I agree it is confusing. But I guess it's valid as it's the only plugin supporting an HSM directly at the moment.
20:17:22 <tkelsey> well not true jaosorior, since we have KMIPSecretStore now
20:17:33 <arunkant> tkelsey: You have a document around how the data flows via sequence diagram in various interactions. Will that be worth sharing to provide clarification?
20:17:35 <jaosorior> lol, crap, forgot about that
20:17:40 <jaosorior> nevermind then
20:17:55 <tkelsey> arunkant: yes, I can find somewhere for that to live and link it
20:18:00 <jaosorior> and we where just talking about it...
20:18:18 <tkelsey> jaosorior: heh easy to do :)
20:18:18 <redrobot> I think we're all in agreement?  We can move on to the next agenda item
20:18:20 <rellerreller> Sort of, but KMIP does not support cryptoprocessing
20:18:29 <tkelsey> redrobot: +1
20:18:41 <jaosorior> yeah, I guess we can move on
20:18:47 <redrobot> #topic Content-Types Blueprint
20:18:50 <redrobot> #link https://review.openstack.org/#/c/145073
20:18:54 <jaosorior> the rest of the feedback can go to the CR anyway
20:18:58 <redrobot> rellerreller anything specific to discuss?
20:19:10 <rellerreller> I actually did not add this item
20:19:24 <woodster_> I added these 3 blueprints
20:19:25 <rellerreller> I was wondering who did
20:19:37 <woodster_> Just to get focus on them
20:19:40 <redrobot> hehe, sorry rellerreller I just assumed...
20:19:47 <rellerreller> I have not received any feedback on this
20:20:02 <woodster_> Other than my comments any other issues folks have?
20:20:22 <jaosorior> I have some trivial questions there
20:20:36 <woodster_> rellerreller: if you can just add the bits I noted I'll +2
20:20:36 <alee> woodster_, rellerreller -- I'll get back to that one today
20:20:58 <rellerreller> woodster_ alee thanks!
20:21:22 <rellerreller> I think we should finalize it soon because I don't want to break all of the secret stores
20:21:31 <rellerreller> before the next release
20:21:43 <redrobot> I'll also try to get a review in today
20:21:49 <woodster_> That might do it for that blueprint then
20:22:28 <redrobot> ok, moving on
20:22:35 <redrobot> #topic Per-Secret Policy
20:22:39 <redrobot> #link https://review.openstack.org/#/c/127353
20:22:43 <redrobot> lots of red in that review
20:23:06 <woodster_> I tried to boil out the bigger question i saw
20:23:37 <redrobot> Open question: Should whitelisted users be able to decrypt secrets even if they don't have proper Barbican roles?
20:23:54 <redrobot> So the use case is,
20:24:01 <redrobot> Bob does not have a role to access Barbican
20:24:11 <redrobot> Alice grants Bob access to a single secret
20:24:17 <redrobot> Should Barbican allow Bob to retrieve the secret?
20:24:35 <redrobot> woodster_ is that an accurate tl;dr?
20:25:05 <woodster_> So essentially bypassing the need for roles to be assigned to them, yep
20:26:40 <tsv> redrobot, trying to understand, does Alice grant Bob access via keystone trust ?
20:27:11 <rm_work> no, it's an internal barbican mechanism
20:27:17 <rm_work> Trusts are not used
20:27:21 <tsv> rm_work, ok. thanks
20:27:29 <redrobot> tsv, no alice grants bob access via Barbican whitelist.  Keystone unfortunately does not support entity-level ACLs
20:27:32 <woodster_> So could a Lbaas user be able to decrypt a secret that a client said they could access? That could be a service user with admin role perhaps...so maybe that's a 2nd question
20:27:35 <arunkant> This seems to be bypassing openstack role based authorization model ..how this play with hierarchial tenants case?
20:27:36 <rellerreller> So are roles now are admin, audit, observer, creator?
20:27:53 <tsv> redrobot, got it
20:28:30 <rm_work> I think it makes some sense to somehow tie a user's ability to access "anything in Barbican" to keystone
20:28:48 <rm_work> unfortunately, the way roles work it really doesn't make sense
20:29:10 <rm_work> since a role is a specific relation of a user to a project
20:29:17 <woodster_> rellerreller: those are Barbican roles, different than the uber admin role which I think gives 'god' access
20:29:39 <rm_work> Bob -> Barbican:Observer -> Bob's Project
20:30:04 <rm_work> what you REALLY want is: Bob -> Barbican:Observer -> Barbican
20:30:15 <rm_work> but that isn't possible AFAIK with Keystone roles
20:30:27 <rm_work> maybe there is a way to work around this?
20:30:35 <woodster_> rm_work: so in this case an OpenStack admin would have to grant a Barbican role to the Lbaas user/project association
20:31:02 <redrobot> rm_work I think the idea would be to check for Bob -> Barbican:(some_role) -> Secret's Project
20:31:15 <rm_work> redrobot: so they'd need a Trust *too*?
20:31:23 <alee> woodster_, by that you mean the Lbaas service user?
20:31:36 <redrobot> rm_work no, i don't think so
20:31:40 <rm_work> for instance, LBaaS's user won't have a Barbican:Observer role for EVERY project that it has access to
20:31:43 <rm_work> it could be thousands
20:32:02 <woodster_> rm_work, it would just need such role for its own project
20:32:21 <rm_work> woodster_: right, that is what you keep saying, and *that* is what doesn't make sense
20:32:44 <woodster_> rm_work, with that role it could then access any secret regardless of if that secret was stored by a different user/projecdt
20:32:56 <rm_work> right, so that isn't a good option either
20:33:35 <alee> woodster_, so if I understand this correctly, roles are tied to projects?
20:33:38 <rm_work> My argument is less "your goal is wrong", and more like "the approach you're proposing is wrong, and I'd rather not do it than do it wrong"
20:33:49 <woodster_> rm_work: the sequence is lbaas user with correct role GETs to barbican with a given secret URI ref...barbican check that the role is ok for decrypt, and then fetches secret by URI and decrypts/returns it
20:33:55 <arunkant> rm_work: So you cannot have a barbican specific admin role and that allow access to all resources based on updated policy rules?
20:34:33 <rm_work> arunkant: well, maybe? but the idea for this feature is for more than just service-users, so trying to do something like that for random cloud users seems like it would be prohibitive
20:34:40 <woodster_> arunkant, the role policy is not tied to a project ID (currently anyway)
20:35:03 <rm_work> alee: roles are tied to projects, yes
20:35:11 <rm_work> think of roles as a mapping between a user and a project
20:35:16 <arunkant> rm_work: Yes..actually issue is entities are created/ managed under a project..so you need token scoped that project?
20:35:18 <woodster_> rm_work, how is that so prohibitive? We make every other direct client get roles assigned first
20:35:26 <rm_work> like, three tables -- USER, PROJECT, ROLE
20:35:40 <woodster_> alee, roles are tied to the user/project assocations
20:35:42 <rm_work> where the ROLE table holds the link between USER and PROJECT, but with an access type field
20:36:00 <tsv> this use case sounds kind of similar to the swift tempurl though
20:36:31 <rm_work> woodster_: because it doesn't *do* anything, because 100% of cloud users will start with a Barbican role for their project -- so the only action from there is to remove their access to Barbican altogether so they can't access secrets that other people gave them access to
20:36:46 <woodster_> arunkant, currently secrets are tied to projects, but this blueprint would break that bond essentially. Now barbican would just look up the entity by its UUID as long as role policy checks pass
20:36:55 <arunkant> rm_work: Can we allow privleged user to create entities under other projects via some project identifier
20:37:25 <woodster_> rm_work, so if the lbaas user will have a barbican role, then we are done discussing :)
20:37:25 <rm_work> arunkant: we're trying to avoid the concept of a "privileged user" (I am assuming you mean like a cloud-admin level user?)
20:37:35 <rm_work> woodster_: it works, but it's *wrong*
20:37:47 <woodster_> rm_work, assuming you meant the lbaas user was in that 100%
20:37:51 <rm_work> yes
20:37:52 <alee> rm_work, woodster_  then I'm not I understand how roles are related to the case where you want someone (the lbaas service user) to gain access to a secret owned by a different project.
20:38:18 <arunkant> rm_work: Yes..something like barbican-service-admin and if someone has that role, then it can create/manage entities on other's behalf..
20:38:24 <woodster_> alee, I was focusing on the case of Alice putthign Bob the user on the whitelist
20:38:54 <woodster_> alee, but that could work with projects on the whitelist as well
20:39:01 <rm_work> woodster_: right, so returning to the metaphor, Bob does have a bank account, but it shouldn't matter
20:39:08 <rm_work> just because he DOES isn't a good reason for the bank to ask
20:39:16 <alee> unless you're talking about giving the lbaas user a role in every project for every secret -- allowing lbaas to access a secret because he happens to have a role in *some* project doesn't make sense.
20:39:29 <rm_work> alee: right, that is what I am getting at
20:39:36 <woodster_> my overall point is that I think the role assignment resolved on any user/project assoc, regardless of the end resource they are acting on, should always satisfy barbican rbac policy constraints
20:40:13 <arunkant> rm_work: Actually I have a similar issue on a Keystone spec where I am trying to provide optional backend for Keystone credential API to use barbican and have similar issue.
20:40:20 <rm_work> alee: it *works* but it's nonsensical
20:40:26 <redrobot> woodster_ sounds to me like you're trying to work around a policy enforcement limitation?
20:40:30 <woodster_> alee, no I'm saying there just has to be *one* user/project with the right role....it can access whatever user/projects are whitelisted for it...the original project the secret was created under doesn't matter to that
20:40:31 <jaosorior> Lbaas having access to all the secrets would be a huge security concern.
20:40:34 <rm_work> and I don't think we should move forward on the basis that "it works, so it must be the right way to do this"
20:40:58 <alee> woodster_, I like rm_work's analogy.  Just because lbaas has a bank account doesn't really mean anything
20:41:06 <woodster_> lbaas user would only have access to the secrets it is whitelisted for
20:41:14 <alee> jaosorior, they can't access any secret -- only the ones where they are whitelisted
20:41:16 <rm_work> jaosorior: totally agree
20:41:28 <rm_work> jaosorior: I was the one who started pushing for this to begin with
20:42:00 <tsv> woodster_, rm_work, swift has the tempurl feature for an user to pass a temporary link to a container/file right ? isn't this scenario comparable ?
20:42:02 <jaosorior> rm_work: from what I read, I agree with you
20:42:23 <rm_work> tsv: possibly -- though the link needs to work essentially *forever*
20:42:25 <rm_work> so not as "temp"
20:42:48 <rm_work> and ideally there's still some user checking
20:42:56 <woodster_> ok, so we are saying Alice must conform to rbac policy, but lbaas doesn't have to for secrets alice granted access to. Correct? If that's the case, then we will need to bypass barbican role checking for the lbaas transaction.
20:43:02 <tsv> rm_work, i agree, but we could possibly look at that and just don't expire it ?
20:43:07 <rm_work> I mean, the check "is this user a keystone user, who is not disabled" is still something I'd assume we would check
20:43:08 <notmyname> rm_work: swift's tempurls are time-limited. but it's entirely possible to set a time of billions of seconds from now
20:43:13 <redrobot> tsv  IIRC ther is a feature in Glance where a user can share an image with another user.  I think this use case is similar to that one.
20:43:24 <alee> woodster_, so I guess your question is -- should the policy be --> role:observer(in some project) and whitelisted ? or role:observer(in secret project) or whitelisted
20:43:39 <alee> woodster_, is that correct?
20:44:09 <woodster_> alee, not sure what the observer means there
20:44:10 <rm_work> so woodster_: if the end-result of sharing a secret from user A to user B was that it shows up in user B's secret list as if it were his own (just without write permissions), then maybe that would make more sense?
20:44:39 <rm_work> then he's really asking about his own secret -- if that makes sense
20:44:44 <bknudson> how are you going to check "is this user a keystone user, who is not disabled" ?
20:44:49 <bknudson> I don't think keystone has an api for that.
20:44:59 <rm_work> bknudson: do we not get that for free by them HAVING a keystone token?
20:45:19 <bknudson> rm_work: yes, you get that for free if you're using a token for the user.
20:45:19 <rm_work> we check the token with keystone, but we're not looking for a specific role -- just not a 403
20:45:21 <woodster_> rm_work, I think there was consensus that GETting a list of secrets would not get all the secrets I have access to, jsut those created for my project.
20:45:31 <rm_work> woodster_: right
20:45:36 <rm_work> I do remember that
20:45:57 <rm_work> bknudson: does that really not work / seem difficult?
20:46:24 <rm_work> it seems to me it should be *trivial* to validate that a user is a valid keystone user, via the token they send in
20:46:26 <bknudson> rm_work: yes, that works. I thought the discussion was about having a different user check if some user wasn't disabled.
20:46:31 <redrobot> woodster_ I think that policy will need to be re-written to allow for the ACL white list.  I think that requiring _some_ role just to satisfy the current policy is not the right way of doing this.
20:46:41 <rm_work> ah -- no, just the service checking
20:46:46 <woodster_> I think the policy would have to be user-has-valid-roles-for-action OR user is on white list....I'm arguing for the AND there
20:47:22 <rm_work> user-has-valid-roles-for-action OR (user-is-valid-user AND user-on-ACL-whitelist)
20:48:27 <redrobot> woodster_ so what is the benefit of requiring both _some_ role AND white list?
20:48:56 <redrobot> btw we only have about 10 min left.  We'll have to bump some agenda items to next week
20:49:01 <rm_work> redrobot: allowing cloud admins to disable the user's access to Barbican completely
20:49:26 <rm_work> redrobot: otherwise, cloud admins could disable the user's Barbican role to THEIR project, and assume the user couldn't access anything in Barbican
20:49:38 <rm_work> but the user would still be able to access anything that had been Whitelisted for them by others
20:49:55 <rm_work> woodster_: correct?
20:50:36 <arunkant> rm_work: +1
20:51:07 <rm_work> (I *believe* I understand what woodster_ is going for, and I don't disagree, I just don't think the way he wants to DO IT makes sense T_T)
20:51:56 <redrobot> rm_work so, I would think that this would require a new role, specifically for Barbican access in general.  Trying to use _some/any_ role to avoid having to specifically define a new role is what feels weird about this.
20:52:10 <rm_work> yes, essentially
20:52:30 <rm_work> I think that might be ok
20:52:40 <rm_work> if there was a "view-whitelisted-secrets" role
20:52:44 <rm_work> that was separate
20:52:55 <redrobot> rm_work +1 yes, that's what I'm thinking
20:53:22 <rm_work> not sure how I missed that obvious solution :P
20:54:01 <arunkant> rm_work..so with new role, how the client is going to create new resources (is it under same project?)...or this new role is just needed for reading and not writing?
20:54:28 <rm_work> needed for any interaction with secrets that are not her own, I assume
20:54:44 <redrobot> arunkant it would be a role that is needed for read only, and it only applies to secrets that were shared via the whitelist.
20:55:11 <arunkant> rm_work: then don't you need token scoped to that project for creating it
20:55:31 <redrobot> arunkant creating secrets isn't changed by this feature
20:55:49 <redrobot> arunkant the whitelist acl only applies to secrets that have already been craeted and are being shared with another user
20:56:11 <redrobot> we're running out of time
20:56:20 <redrobot> and I think we may have lost woodster_ ...
20:56:29 <arunkant> redrobot: okay..that's why I asked whether its for writing or not?.
20:57:05 <alee> rm_work, redrobot this seems reasonable to me
20:57:06 <rm_work> I … guess not for writing
20:57:20 <rm_work> though IIRC there was something about read-only and not-read-only in the spec
20:57:22 <rm_work> would have to reread
20:57:41 <redrobot> yeah, I think we'll need to revisit this next week to make sure woodster_ agrees
20:57:42 <rm_work> but not-read-only would be weird since you can't WRITE to anything currently in Barbican <_<
20:57:48 <tsv> redrobot, i got to run for another meeting too. i know woodster added the next agenda for quota
20:58:10 <redrobot> tsv yeah, we're out of time.  we'll revisit everything we didn't get to next week
20:58:15 <rm_work> I *think* we got a decent solution/consensus so hopefully woodster will be good with this
20:58:18 <redrobot> thanks for joining everyone.
20:58:24 <rm_work> sorry for taking the whole meeting :P
20:58:32 <redrobot> rm_work no worries, that's what these meetings are for :)
20:58:32 <rm_work> err -- at least half of it
20:58:33 <tsv> redrobot, sure. thanks
20:58:40 <rm_work> alright, thanks guys
20:58:46 <rm_work> and gals
20:58:50 <rm_work> ;)
20:59:26 <redrobot> #endmeeting