20:01:13 #startmeeting barbican 20:01:14 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:17 The meeting name has been set to 'barbican' 20:01:22 #topic Roll Call 20:01:27 o/ 20:01:29 o/ 20:01:30 o/ 20:01:31 o/ 20:01:35 o/ 20:01:36 o/ 20:01:37 o/ 20:01:40 o/ 20:01:40 o/ 20:01:43 o/ 20:01:47 o/ 20:02:03 o/ 20:02:11 lots of barbicaneers here today! 20:02:16 good thing because we have a full agenda 20:02:21 which, as usual, can be found here: 20:02:27 o/ 20:02:35 #link https://wiki.openstack.org/wiki/Meetings/Barbican 20:03:05 o/ 20:03:24 ok, let's get this started 20:03:35 #topic KMIP MKEK 20:03:53 #link https://review.openstack.org/#/c/148948 20:03:54 o/ 20:04:08 TL:DR; We thought we were building something similar to the p11 plugin for KMIP 20:04:08 ok, so this is the spec #https://review.openstack.org/#/c/148948/ 20:04:20 ah redrobot got there before me :) 20:04:42 so I would of course like input on the spec 20:04:51 ok, so I was looking over the spec earlier 20:04:56 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 yeah, I think there was some confusion on whether this would be new plugin or not 20:05:28 I think there is also confusion over how this differs from the P11/HSM secret store 20:05:46 We see it as being a completely separate plugin to the current KMIP secret store 20:05:54 in no way a replacement, just a different approach 20:06:10 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 Clarification is always good 20:06:35 +1 to different plugin than KMIPSecretStore 20:06:39 I have updated the spec a moment ago to try and be more clear about thinks :) 20:06:42 *things 20:06:51 yeah, I gave the +2 to that spec, on the basis that this will be a separate plugin 20:06:59 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 exactly 20:07:33 Do we need a whole new plugin for that or just tweak the p11 plugin? 20:07:54 KMIP and P11 work very differently in places 20:07:56 rellerreller: I think that would make things pretty confusing 20:08:09 and the kmip library doesn’t currently support the fancy features that p11 leverages 20:08:11 jaosorior: +1 20:08:14 like in-HSM session keys 20:08:55 I agree with that. I was wondering what the pain would be because most of the business logic sounds the same. 20:09:23 For instance, create a MKEK then create a KEK for each project. Encrypt each key with a KEK. 20:09:58 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 The p11 plugin is massive 20:10:03 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 Just wanted to raise the question because seem similar. 20:10:20 One day perhaps things could be abstracted away significantly 20:10:32 but the p11 plugin uses all of PKCS#11 functionality 20:10:41 Our KMIP one wont use all KMIP functionality 20:10:48 as most of it isn’t in the pykmip library yet 20:11:02 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 So the data flow and interaction will actually be different in a number of places 20:11:20 jaosorior maybe not premature anymore :) 20:11:52 hyakuhei: so will encrypt keys need to exist unencrypted outside hsm? I haven't looked at details yet 20:11:58 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 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 ^ is what I’d say in person if you could see my face and intonation 20:12:34 hyakuhei :) 20:12:36 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 kyakuhei: chillax 20:13:16 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 Anyway, I think the plugin should go as is proposed at the moment. And we can think about refactoring later 20:13:29 jaosorior: +1 20:13:31 :) 20:13:48 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 jaosorior +1 as well 20:14:11 anyway I think its better to have to models of MKEK before trying to factor out comonality 20:14:19 +1 20:14:22 tkelsey: exactly 20:14:50 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 redrobot: agreed 20:15:16 agreed 20:15:37 if people think there is room to clarify the spec more in that regard then please drop feedback in gerrit 20:15:40 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 +1 tkelsey do you think we can clarify more ? 20:15:58 and maybe stop calling the p11 plugin ‘HSM’ ? 20:16:14 As that is _super_ confusing for some of us :P 20:16:18 hyakuhei: I can give it another pass, but take a look at the stuff I just put up as well 20:16:37 jaosorior I'm sure we'll get to bikeshed a name for the plugin class once the implementation is in review :) 20:16:39 cool, thanks. 20:17:02 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 well not true jaosorior, since we have KMIPSecretStore now 20:17:33 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 lol, crap, forgot about that 20:17:40 nevermind then 20:17:55 arunkant: yes, I can find somewhere for that to live and link it 20:18:00 and we where just talking about it... 20:18:18 jaosorior: heh easy to do :) 20:18:18 I think we're all in agreement? We can move on to the next agenda item 20:18:20 Sort of, but KMIP does not support cryptoprocessing 20:18:29 redrobot: +1 20:18:41 yeah, I guess we can move on 20:18:47 #topic Content-Types Blueprint 20:18:50 #link https://review.openstack.org/#/c/145073 20:18:54 the rest of the feedback can go to the CR anyway 20:18:58 rellerreller anything specific to discuss? 20:19:10 I actually did not add this item 20:19:24 I added these 3 blueprints 20:19:25 I was wondering who did 20:19:37 Just to get focus on them 20:19:40 hehe, sorry rellerreller I just assumed... 20:19:47 I have not received any feedback on this 20:20:02 Other than my comments any other issues folks have? 20:20:22 I have some trivial questions there 20:20:36 rellerreller: if you can just add the bits I noted I'll +2 20:20:36 woodster_, rellerreller -- I'll get back to that one today 20:20:58 woodster_ alee thanks! 20:21:22 I think we should finalize it soon because I don't want to break all of the secret stores 20:21:31 before the next release 20:21:43 I'll also try to get a review in today 20:21:49 That might do it for that blueprint then 20:22:28 ok, moving on 20:22:35 #topic Per-Secret Policy 20:22:39 #link https://review.openstack.org/#/c/127353 20:22:43 lots of red in that review 20:23:06 I tried to boil out the bigger question i saw 20:23:37 Open question: Should whitelisted users be able to decrypt secrets even if they don't have proper Barbican roles? 20:23:54 So the use case is, 20:24:01 Bob does not have a role to access Barbican 20:24:11 Alice grants Bob access to a single secret 20:24:17 Should Barbican allow Bob to retrieve the secret? 20:24:35 woodster_ is that an accurate tl;dr? 20:25:05 So essentially bypassing the need for roles to be assigned to them, yep 20:26:40 redrobot, trying to understand, does Alice grant Bob access via keystone trust ? 20:27:11 no, it's an internal barbican mechanism 20:27:17 Trusts are not used 20:27:21 rm_work, ok. thanks 20:27:29 tsv, no alice grants bob access via Barbican whitelist. Keystone unfortunately does not support entity-level ACLs 20:27:32 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 This seems to be bypassing openstack role based authorization model ..how this play with hierarchial tenants case? 20:27:36 So are roles now are admin, audit, observer, creator? 20:27:53 redrobot, got it 20:28:30 I think it makes some sense to somehow tie a user's ability to access "anything in Barbican" to keystone 20:28:48 unfortunately, the way roles work it really doesn't make sense 20:29:10 since a role is a specific relation of a user to a project 20:29:17 rellerreller: those are Barbican roles, different than the uber admin role which I think gives 'god' access 20:29:39 Bob -> Barbican:Observer -> Bob's Project 20:30:04 what you REALLY want is: Bob -> Barbican:Observer -> Barbican 20:30:15 but that isn't possible AFAIK with Keystone roles 20:30:27 maybe there is a way to work around this? 20:30:35 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 rm_work I think the idea would be to check for Bob -> Barbican:(some_role) -> Secret's Project 20:31:15 redrobot: so they'd need a Trust *too*? 20:31:23 woodster_, by that you mean the Lbaas service user? 20:31:36 rm_work no, i don't think so 20:31:40 for instance, LBaaS's user won't have a Barbican:Observer role for EVERY project that it has access to 20:31:43 it could be thousands 20:32:02 rm_work, it would just need such role for its own project 20:32:21 woodster_: right, that is what you keep saying, and *that* is what doesn't make sense 20:32:44 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 right, so that isn't a good option either 20:33:35 woodster_, so if I understand this correctly, roles are tied to projects? 20:33:38 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 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 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 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 arunkant, the role policy is not tied to a project ID (currently anyway) 20:35:03 alee: roles are tied to projects, yes 20:35:11 think of roles as a mapping between a user and a project 20:35:16 rm_work: Yes..actually issue is entities are created/ managed under a project..so you need token scoped that project? 20:35:18 rm_work, how is that so prohibitive? We make every other direct client get roles assigned first 20:35:26 like, three tables -- USER, PROJECT, ROLE 20:35:40 alee, roles are tied to the user/project assocations 20:35:42 where the ROLE table holds the link between USER and PROJECT, but with an access type field 20:36:00 this use case sounds kind of similar to the swift tempurl though 20:36:31 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 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 rm_work: Can we allow privleged user to create entities under other projects via some project identifier 20:37:25 rm_work, so if the lbaas user will have a barbican role, then we are done discussing :) 20:37:25 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 woodster_: it works, but it's *wrong* 20:37:47 rm_work, assuming you meant the lbaas user was in that 100% 20:37:51 yes 20:37:52 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 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 alee, I was focusing on the case of Alice putthign Bob the user on the whitelist 20:38:54 alee, but that could work with projects on the whitelist as well 20:39:01 woodster_: right, so returning to the metaphor, Bob does have a bank account, but it shouldn't matter 20:39:08 just because he DOES isn't a good reason for the bank to ask 20:39:16 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 alee: right, that is what I am getting at 20:39:36 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 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 alee: it *works* but it's nonsensical 20:40:26 woodster_ sounds to me like you're trying to work around a policy enforcement limitation? 20:40:30 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 Lbaas having access to all the secrets would be a huge security concern. 20:40:34 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 woodster_, I like rm_work's analogy. Just because lbaas has a bank account doesn't really mean anything 20:41:06 lbaas user would only have access to the secrets it is whitelisted for 20:41:14 jaosorior, they can't access any secret -- only the ones where they are whitelisted 20:41:16 jaosorior: totally agree 20:41:28 jaosorior: I was the one who started pushing for this to begin with 20:42:00 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 rm_work: from what I read, I agree with you 20:42:23 tsv: possibly -- though the link needs to work essentially *forever* 20:42:25 so not as "temp" 20:42:48 and ideally there's still some user checking 20:42:56 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 rm_work, i agree, but we could possibly look at that and just don't expire it ? 20:43:07 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 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 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 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 woodster_, is that correct? 20:44:09 alee, not sure what the observer means there 20:44:10 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 then he's really asking about his own secret -- if that makes sense 20:44:44 how are you going to check "is this user a keystone user, who is not disabled" ? 20:44:49 I don't think keystone has an api for that. 20:44:59 bknudson: do we not get that for free by them HAVING a keystone token? 20:45:19 rm_work: yes, you get that for free if you're using a token for the user. 20:45:19 we check the token with keystone, but we're not looking for a specific role -- just not a 403 20:45:21 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 woodster_: right 20:45:36 I do remember that 20:45:57 bknudson: does that really not work / seem difficult? 20:46:24 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 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 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 ah -- no, just the service checking 20:46:46 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 user-has-valid-roles-for-action OR (user-is-valid-user AND user-on-ACL-whitelist) 20:48:27 woodster_ so what is the benefit of requiring both _some_ role AND white list? 20:48:56 btw we only have about 10 min left. We'll have to bump some agenda items to next week 20:49:01 redrobot: allowing cloud admins to disable the user's access to Barbican completely 20:49:26 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 but the user would still be able to access anything that had been Whitelisted for them by others 20:49:55 woodster_: correct? 20:50:36 rm_work: +1 20:51:07 (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 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 yes, essentially 20:52:30 I think that might be ok 20:52:40 if there was a "view-whitelisted-secrets" role 20:52:44 that was separate 20:52:55 rm_work +1 yes, that's what I'm thinking 20:53:22 not sure how I missed that obvious solution :P 20:54:01 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 needed for any interaction with secrets that are not her own, I assume 20:54:44 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 rm_work: then don't you need token scoped to that project for creating it 20:55:31 arunkant creating secrets isn't changed by this feature 20:55:49 arunkant the whitelist acl only applies to secrets that have already been craeted and are being shared with another user 20:56:11 we're running out of time 20:56:20 and I think we may have lost woodster_ ... 20:56:29 redrobot: okay..that's why I asked whether its for writing or not?. 20:57:05 rm_work, redrobot this seems reasonable to me 20:57:06 I … guess not for writing 20:57:20 though IIRC there was something about read-only and not-read-only in the spec 20:57:22 would have to reread 20:57:41 yeah, I think we'll need to revisit this next week to make sure woodster_ agrees 20:57:42 but not-read-only would be weird since you can't WRITE to anything currently in Barbican <_< 20:57:48 redrobot, i got to run for another meeting too. i know woodster added the next agenda for quota 20:58:10 tsv yeah, we're out of time. we'll revisit everything we didn't get to next week 20:58:15 I *think* we got a decent solution/consensus so hopefully woodster will be good with this 20:58:18 thanks for joining everyone. 20:58:24 sorry for taking the whole meeting :P 20:58:32 rm_work no worries, that's what these meetings are for :) 20:58:32 err -- at least half of it 20:58:33 redrobot, sure. thanks 20:58:40 alright, thanks guys 20:58:46 and gals 20:58:50 ;) 20:59:26 #endmeeting