Friday, 2017-06-09

*** thorst_afk has joined #openstack-keystone00:00
*** jamielennox|away is now known as jamielennox00:02
*** spzala has joined #openstack-keystone00:21
*** spzala has quit IRC00:26
*** thorst_afk has quit IRC00:33
*** spzala has joined #openstack-keystone00:38
*** thorst_afk has joined #openstack-keystone00:42
*** thorst_afk has quit IRC00:43
*** lucasxu has joined #openstack-keystone00:46
*** lucasxu has quit IRC00:46
*** zhurong has joined #openstack-keystone00:49
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone master: Move grant policies to DocumentedRuleDefault
*** cheran has joined #openstack-keystone00:58
*** jamielennox is now known as jamielennox|away01:00
*** jamielennox|away is now known as jamielennox01:10
*** thorst_afk has joined #openstack-keystone01:14
gagehugocheran awesome01:19
*** 7GHAA59HN has joined #openstack-keystone01:20
*** liujiong has joined #openstack-keystone01:22
*** aojea has joined #openstack-keystone01:23
*** aojea has quit IRC01:27
*** zhurong has quit IRC01:29
*** spzala has quit IRC01:30
*** 7GHAA59HN has quit IRC01:30
*** shuyingy_ has joined #openstack-keystone01:30
openstackgerritGage Hugo proposed openstack/keystone master: Add project tags api-ref document and reno
*** thorst_afk has quit IRC01:31
*** piliman974 has quit IRC01:33
*** piliman974 has joined #openstack-keystone01:35
*** markvoelker has joined #openstack-keystone01:35
*** namnh has joined #openstack-keystone01:37
*** thorst_afk has joined #openstack-keystone01:38
*** dave-mccowan has joined #openstack-keystone01:38
*** thorst_afk has quit IRC01:44
*** r-daneel has quit IRC01:47
openstackgerritGage Hugo proposed openstack/keystone master: Add project tags api-ref document and reno
*** piliman974 has quit IRC01:59
*** zhurong has joined #openstack-keystone02:04
openstackgerritGage Hugo proposed openstack/keystone master: Add project tags api-ref documentation and reno
*** thorst_afk has joined #openstack-keystone02:06
*** Shunli has joined #openstack-keystone02:08
*** markvoelker has quit IRC02:09
openstackgerritzhengliuyang proposed openstack/keystone master: Redundant conflict exception ensure default role
*** thorst_afk has joined #openstack-keystone02:37
*** zsli_ has joined #openstack-keystone02:38
*** zsli__ has joined #openstack-keystone02:41
*** Shunli has quit IRC02:41
*** Shunli has joined #openstack-keystone02:43
*** zsli_ has quit IRC02:44
*** markvoelker has joined #openstack-keystone02:44
*** zsli__ has quit IRC02:45
*** thorst_afk has quit IRC02:48
*** spzala has joined #openstack-keystone02:53
*** spzala_ has joined #openstack-keystone02:53
*** spzala has quit IRC02:53
*** ducttape_ has joined #openstack-keystone02:59
*** phalmos has quit IRC03:02
*** ducttape_ has quit IRC03:05
*** ducttape_ has joined #openstack-keystone03:11
*** ducttape_ has quit IRC03:16
*** cheran has quit IRC03:17
*** dikonoor has joined #openstack-keystone03:27
*** ducttape_ has joined #openstack-keystone03:33
openstackgerritzhengliuyang proposed openstack/keystone master: Add annotation about token authenticate
*** thorst_afk has joined #openstack-keystone03:45
*** ducttape_ has quit IRC03:46
*** dave-mccowan has quit IRC03:47
*** ducttape_ has joined #openstack-keystone03:52
*** ducttap__ has joined #openstack-keystone03:58
*** spzala_ has quit IRC04:00
*** ducttape_ has quit IRC04:01
*** ducttape_ has joined #openstack-keystone04:03
*** thorst_afk has quit IRC04:04
*** ducttap__ has quit IRC04:05
*** ducttape_ has quit IRC04:06
*** ducttape_ has joined #openstack-keystone04:10
*** spzala has joined #openstack-keystone04:17
*** ducttape_ has quit IRC04:17
*** links has joined #openstack-keystone04:20
*** spzala has quit IRC04:21
*** zhurong has quit IRC04:25
*** zhurong has joined #openstack-keystone04:34
*** aselius has quit IRC04:36
*** gyee has quit IRC04:49
*** spzala has joined #openstack-keystone04:58
*** spzala has quit IRC05:03
*** Guest72612 has quit IRC05:06
*** mfisch` has quit IRC05:06
*** med_ has joined #openstack-keystone05:06
*** mfisch has joined #openstack-keystone05:06
*** mfisch has quit IRC05:06
*** mfisch has joined #openstack-keystone05:06
*** med_ is now known as Guest651105:06
*** links has quit IRC05:10
*** aselius_ has joined #openstack-keystone05:12
*** tobberydberg has joined #openstack-keystone05:18
*** tobberydberg has quit IRC05:22
*** links has joined #openstack-keystone05:26
*** spzala has joined #openstack-keystone05:33
*** shuyingy_ has quit IRC05:33
*** shuyingy_ has joined #openstack-keystone05:34
*** spzala has quit IRC05:38
*** tobberydberg has joined #openstack-keystone05:41
*** nicolasbock has joined #openstack-keystone05:57
*** thorst_afk has joined #openstack-keystone06:02
*** nicolasbock has quit IRC06:02
*** thorst_afk has quit IRC06:06
*** spzala has joined #openstack-keystone06:13
*** nishaYadav has joined #openstack-keystone06:15
*** spzala has quit IRC06:18
*** jaosorior has joined #openstack-keystone06:18
*** edmondsw has joined #openstack-keystone06:43
*** edmondsw has quit IRC06:47
*** tesseract has joined #openstack-keystone06:53
*** zhurong has quit IRC06:55
*** spzala has joined #openstack-keystone06:55
*** zhurong has joined #openstack-keystone06:56
*** zhurong has quit IRC06:57
*** spzala has quit IRC06:59
*** thorst_afk has joined #openstack-keystone07:03
*** pcaruana has joined #openstack-keystone07:05
*** thorst_afk has quit IRC07:07
*** markvoelker has quit IRC07:08
cmurphymorgan: jamielennox mordred all I cared about was not bundling an unrelated change into the endpointdata patch07:08
*** links has quit IRC07:09
*** rcernin has joined #openstack-keystone07:09
*** spzala has joined #openstack-keystone07:11
*** spzala has quit IRC07:16
*** aselius_ has quit IRC07:21
*** links has joined #openstack-keystone07:25
*** aojea has joined #openstack-keystone07:31
*** bigjools has quit IRC07:36
*** bigjools has joined #openstack-keystone07:40
*** bigjools has quit IRC07:41
*** bigjools has joined #openstack-keystone07:41
openstackgerritColleen Murphy proposed openstack/keystone-specs master: Application Credentials for application authn
cmurphymorgan: mordred lbragstad updated ^07:41
*** namnh has quit IRC07:58
*** zzzeek has quit IRC08:00
*** zzzeek has joined #openstack-keystone08:00
*** spzala has joined #openstack-keystone08:03
*** thorst_afk has joined #openstack-keystone08:03
*** spzala has quit IRC08:07
*** thorst_afk has quit IRC08:23
*** nishaYadav has quit IRC08:29
*** spzala has joined #openstack-keystone08:29
*** spzala has quit IRC08:34
*** shuying__ has joined #openstack-keystone08:36
*** shuyingy_ has quit IRC08:39
openstackgerritqtlu proposed openstack/keystone-specs master: Fix html_last_updated_fmt for Python3
*** spzala has joined #openstack-keystone09:00
*** spzala has quit IRC09:05
*** markvoelker has joined #openstack-keystone09:13
*** thorst_afk has joined #openstack-keystone09:20
*** jpena has joined #openstack-keystone09:24
*** thorst_afk has quit IRC09:24
jpenahi, are there any plans for a new python-keystoneclient release anytime soon?09:24
*** spzala has joined #openstack-keystone09:27
*** Shunli has quit IRC09:31
*** spzala has quit IRC09:32
openstackgerritPallavi proposed openstack/ldappool master: Fix html_last_updated_fmt for Python3.
*** markvoelker has quit IRC09:42
openstackgerritMerged openstack/ldappool master: Fix html_last_updated_fmt for Python3.
*** links has quit IRC09:51
*** liujiong has quit IRC09:52
*** zhurong has joined #openstack-keystone09:55
*** spzala has joined #openstack-keystone09:59
*** namnh has joined #openstack-keystone10:03
*** links has joined #openstack-keystone10:03
*** spzala has quit IRC10:04
openstackgerritLingyong Xu proposed openstack/keystonemiddleware master: Fix html_last_updated_fmt for Python3
*** zhurong has quit IRC10:06
*** edmondsw has joined #openstack-keystone10:19
*** piliman974 has joined #openstack-keystone10:21
*** edmondsw has quit IRC10:24
*** spzala has joined #openstack-keystone10:27
*** spzala has quit IRC10:32
*** markvoelker has joined #openstack-keystone10:39
*** nicolasbock has joined #openstack-keystone10:45
*** spzala has joined #openstack-keystone10:58
*** spzala has quit IRC11:02
*** markvoelker has quit IRC11:13
*** ducttape_ has joined #openstack-keystone11:18
*** ducttape_ has quit IRC11:23
*** spzala has joined #openstack-keystone11:29
*** nishaYadav has joined #openstack-keystone11:32
*** spzala has quit IRC11:34
*** edmondsw has joined #openstack-keystone11:42
*** raildo has joined #openstack-keystone11:49
*** xuhaigang has quit IRC11:50
*** aojea has quit IRC11:53
*** namnh has quit IRC11:55
*** thorst_afk has joined #openstack-keystone11:59
*** spzala has joined #openstack-keystone12:00
*** ducttape_ has joined #openstack-keystone12:02
*** spzala has quit IRC12:04
*** ducttape_ has quit IRC12:07
*** xuhaigang has joined #openstack-keystone12:07
*** markvoelker has joined #openstack-keystone12:10
*** ducttape_ has joined #openstack-keystone12:21
*** ducttap__ has joined #openstack-keystone12:22
*** ducttap__ has quit IRC12:22
*** ducttape_ has quit IRC12:25
*** spzala has joined #openstack-keystone12:28
*** jpena is now known as jpena|lunch12:28
*** spzala has quit IRC12:33
*** markvoelker has quit IRC12:36
*** markvoelker has joined #openstack-keystone12:36
*** jaosorior has quit IRC12:37
*** shuying__ has quit IRC12:38
*** catintheroof has joined #openstack-keystone12:40
*** dave-mccowan has joined #openstack-keystone12:43
*** catintheroof has quit IRC12:45
*** catintheroof has joined #openstack-keystone12:46
*** ducttape_ has joined #openstack-keystone12:48
*** links has quit IRC12:48
*** ducttape_ has quit IRC12:53
*** aojea has joined #openstack-keystone12:54
*** aojea has quit IRC12:59
*** spzala has joined #openstack-keystone12:59
mordredmorgan, cmurphy: I'm fine with any of it- I agree, at the very least it does not need to be in these patches13:02
*** lucasxu has joined #openstack-keystone13:03
*** spzala has quit IRC13:03
*** ducttape_ has joined #openstack-keystone13:05
*** shuyingy_ has joined #openstack-keystone13:11
*** ducttape_ has quit IRC13:12
*** shuyingy_ has quit IRC13:15
*** lucasxu has quit IRC13:16
*** ducttape_ has joined #openstack-keystone13:16
*** ducttape_ has quit IRC13:16
*** ducttape_ has joined #openstack-keystone13:17
*** ducttape_ has quit IRC13:21
*** aojea has joined #openstack-keystone13:22
*** aojea has quit IRC13:26
*** spzala has joined #openstack-keystone13:29
*** spzala has quit IRC13:31
*** spzala has joined #openstack-keystone13:31
*** aojea has joined #openstack-keystone13:33
openstackgerritMonty Taylor proposed openstack/keystoneauth master: Rework EndpointData construction to normalize catalog first
mordredmorgan, cmurphy: k. that's rebased on morgan's patch to remove self, then fixed the review comments13:36
mordredI'm thinking maybe not rebase the whole stack while we iterate on those two13:37
*** jpena|lunch is now known as jpena13:38
*** spilla has joined #openstack-keystone13:41
*** chlong has joined #openstack-keystone13:51
*** jaosorior has joined #openstack-keystone13:56
mordredmorgan: or - maybe since I'm rebasing low in the stack I just squash the two so we can shift the larger discusion13:58
*** pnavarro has joined #openstack-keystone13:59
*** nicolasbock has quit IRC14:03
*** lucasxu has joined #openstack-keystone14:09
*** lucasxu has quit IRC14:14
*** lucasxu has joined #openstack-keystone14:14
*** lucasxu has quit IRC14:16
*** tesseract has quit IRC14:16
*** aselius_ has joined #openstack-keystone14:19
lbragstadjpena: i just reviewed the same release for python-keystoneclient you reviewed14:20
*** lucasxu has joined #openstack-keystone14:20
*** tesseract has joined #openstack-keystone14:23
*** lucasxu has quit IRC14:23
*** dikonoor has quit IRC14:28
*** phalmos has joined #openstack-keystone14:29
*** dikonoor has joined #openstack-keystone14:30
*** tobberydberg has quit IRC14:30
*** tobberydberg has joined #openstack-keystone14:33
*** tobberydberg has quit IRC14:39
*** Dinesh_Bhor has quit IRC14:44
*** ducttape_ has joined #openstack-keystone14:44
*** ducttape_ has quit IRC14:46
*** ducttape_ has joined #openstack-keystone14:46
*** jpena is now known as jpena|off14:56
morganmordred: makes sense to me14:56
-openstackstatus- NOTICE: The Gerrit service on is being restarted now to clear an issue arising from an unanticipated SSH API connection flood14:56
*** jpena|off is now known as jpena14:58
*** rcernin has quit IRC15:08
*** jaosorior has quit IRC15:09
*** rderose has joined #openstack-keystone15:18
*** aselius_ has quit IRC15:26
*** aselius has joined #openstack-keystone15:26
*** tobberydberg has joined #openstack-keystone15:31
*** tobberydberg has quit IRC15:36
openstackgerritNicolas Helgeson proposed openstack/keystone master: Added versions to keyston headers
nishaYadavanyone around? I was wondering what's the official logo of keystone15:38
lbragstadnishaYadav: o/15:39
nishaYadavlbragstad, hey!15:39
lbragstadnishaYadav: you can find the mascots here -
openstackgerritColleen Murphy proposed openstack/keystone-specs master: Application Credentials for application authn
cmurphylbragstad: rderose ^15:41
rderosecmurphy: ++15:41
nishaYadavlbragstad, thanks, I was guessing the turle but wasn't sure. The link will help me for other projects too :)15:41
lbragstadrderose: \o/15:44
lbragstadcmurphy: is there any reason to not just include those attributes when we need them in a subsequent release or implementation?15:45
lbragstadit would be an additive feature/change, so it shouldn't be backwards incompatible in anyway15:45
cmurphylbragstad: my reasoning was that since they're not fleshed out yet, if we decide to change them at all it's harder to change after we've committed to the API, whereas adding new parameters is easier15:45
lbragstadi know i tripped on those definitions until i saw the disclaimer in the last sentence15:46
rderoselbragstad: :)15:47
cmurphylbragstad: hmm so what's your suggestion? it wouldn't be additive if we've implemented enough of it to produce an error on a non-empty list15:51
*** aojea has quit IRC15:51
lbragstadcmurphy: oh - my suggestion was completely remove it from the first iteration15:51
lbragstadand then add those attributes when we need them15:52
lbragstadmaking it a completely additive change15:52
cmurphylbragstad: that makes sense to me15:52
lbragstadcmurphy: otherwise - i do share your concern15:52
*** gyee has joined #openstack-keystone15:53
lbragstadit's kinda tough to define the attributes, but not use them and keep them open for implementation "at some point in the future"15:53
cmurphylbragstad: what if we just add "In the next iteration, we will add parameters that will look something like this:"15:53
cmurphymordred: ^15:53
lbragstadcmurphy: yes - we could even have a short section in there specification for that15:53
lbragstadlike - "at the time of this writing, we find these attributes useful for these reasons, but we're not going to implement them in the first pass"15:54
*** dikonoor has quit IRC15:57
lbragstadcmurphy: updated with a comment15:59
cmurphylbragstad: ty15:59
*** jpena is now known as jpena|away16:01
*** r-daneel has joined #openstack-keystone16:01
cmurphyhmm I'm noticing we have "Assigned the current role the creating User has on a Project, optionally accepting a list of roles that is a subset of the creating User's roles in that project." but we don't have a parameter for roles yet16:01
cmurphythat part is something that we'd want to do on the first round16:01
*** f13o has joined #openstack-keystone16:05
f13oWhere can I read more on how Heat is treated from the PoV of other service policy.json? for example nova or neutron16:07
f13oIf a cloud user can use heat api, how should I setup my neutron's policy.json so that my cloud user cannot add more private neutron networks (for example)?16:09
f13o(via heat api and using neutron api)16:09
openstackgerritColleen Murphy proposed openstack/keystone-specs master: Application Credentials for application authn
cmurphylbragstad: rderose ^16:19
rderosecmurphy: ++16:20
*** dikonoor has joined #openstack-keystone16:21
mordredcmurphy, lbragstad: maybe lets add a description of an endpoint that can be queried now that exposes if limiting exists16:25
mordredso that a user can discover whether their cloud supports the next thing or not16:25
mordredsince we _know_ it's a thing that we want in th efuture, but we don't know yet what it looks like, so we know there will be clouds that have credentials but not limits to them, and also clouds that will have both16:26
mordredI mean, it opens a slight can of worms because it would be the beginning of a "capabilities" endpoint - but that would be great anyway :)16:27
*** tesseract has quit IRC16:32
*** pcaruana has quit IRC16:34
lbragstadmordred: an endpoint for limiting?16:39
lbragstadfor application credentials?16:39
cmurphylimiting == permission restricting ya ?16:40
cmurphymordred: can you propose that?16:40
lbragstadi'm not sure i understand why we'd need a separate endpoint for limiting16:40
*** piliman974 has quit IRC16:40
lbragstadthe attributes would either be in the application credential or not, right?16:40
* lbragstad might be by himself in left field16:41
*** piliman974 has joined #openstack-keystone16:43
*** f13o has quit IRC16:44
*** rcernin has joined #openstack-keystone16:45
cmurphymordred is just on a version discovery rampage16:49
*** f13o has joined #openstack-keystone17:00
cmurphylbragstad: rderose mordred I'm afk for ~45 minutes, please update the spec if you reach a consensus17:02
lbragstadcmurphy: ack17:03
mordredcmurphy: I can propose that - I can also do it as a separate thing real quick - Idon't think we should block the spec on that17:07
mordredlbragstad: I mostly want to push back on adding functionality with no way for a user to know if the functionality is supported as much as I can17:08
samueldmqhey ya17:08
lbragstadmordred: so you do want the unused attributes `api_access_list` and `api_access` included in the first iteration?17:09
mordredlbragstad: I don't think we need them there if we can *hand wave* agree to put something somewhere that will let a user know whether or not they can send them17:09
lbragstadmordred: oh - sure, i would be in favor of completely removing those attributes from the application credential object for the first iteration, and then we can document our thinking and why it would be a good thing to add in the future17:10
mordredlbragstad: ++17:10
lbragstadmordred: i think that would address the concern that I had a few patch sets ago as well as rderose's17:11
mordredcool. cmurphy is afk so I'll do that rev right now17:11
lbragstadmordred: awesome17:11
*** aojea has joined #openstack-keystone17:15
*** aojea has quit IRC17:19
mordredlbragstad, cmurphy: in the spec, we have roles in a coupe of places and role_ids in a couple of places17:21
mordredlbragstad: which do you think we should use?17:21
mordredlbragstad: maybe roles - but have the requests accept name or id and the responses always return id?17:22
lbragstadmordred: morgan had a good point about role names17:22
mordredoh - he did? crap, I missed it17:22
* mordred goes back to look17:22
lbragstadmordred: yeah - cmurphy addressed the comment i think17:22
*** jpena|away is now known as jpena17:22
mordredah- his point was just use names, yeah?17:22
morgansince names are used *everywhere*17:22
mordredthere's still a coupe of role_id places - I'll fix them in this rev17:23
*** jpena is now known as jpena|off17:23
ayoungcmurphy,   how about like this:17:35
openstackgerritMonty Taylor proposed openstack/keystone-specs master: Application Credentials for application authn
mordredcmurphy, morgan, lbragstad, rderose: updated17:36
ayoungan application credential is always scoped to a project, and will  include a subset of the roles assigned to the user for that project17:36
ayoungand we have an update...reading17:36
ayoungLGTM morgan17:37
openstackgerritNicolas Helgeson proposed openstack/keystone master: Added versions to keyston headers
ayoungmorgan, quick question, would it be ok to implicitly create a trust when creating an application credential, and then have that show up in the list of trusts?17:38
morganayoung: uhm. maybe?17:38
morganyou should ask mordred though17:38
ayoungits an implementation detail. but should speed the implementation17:38
morganit's his spec ;)17:38
ayoungmorgan, think he's pragmatic enough to say "sure"17:38
ayoungmorgan, are you working on an impl?17:39
morgani am not17:39
ayoungmordred, are you working on an impl17:39
ayoungmorgan, its your fault for having the same 3 letter prefix to your nick17:39
mordredayoung: I don't think that's problematic at all17:40
ayoungcmurphy, regarding your question:17:40
morganmordred: i do have one other question (impl detail), when a user creates a app cred, it is deleteable by any other user with write on the project... this seems oddly asymmetrical from an authn stance where a writer might want to create an action for a user they aren't.17:40
morganyou must be user X to make an app cred for user X17:41
mordredayoung: although, since a trust is a delegation of a user's credentials, would the trust associated with a application credential imply an incorrect thing to a person looking at them?17:41
morganbut any user in W group can delete user X's app cred17:41
mordredespecially if/when roles on a user change or the user is deleted? (I'm fine with that if it does, just asking)17:41
ayoungmordred, so a trust goes from one user (trustor) to another (trustee).  In this case, a trustee would be the application, not a human17:41
lbragstadi don't think a user can specify the user id for an app cred, i think it's populated from the request17:41
* morgan would have assumed it would be a separate permission/policy hook point (regardless of the default being any-writer) 17:41
morganfor delete-not-my-app-cred17:41
morgansomething like is_owner or project_admin17:42
morganor w/e17:42
ayoungwe'd have to fudge a little on the application to make it a user, but we could fake that out by putting it in a hidden domain, much like we proposed doing with consumers for oauth17:42
cmurphymordred: re roles vs role_ids i was trying to address morgan's comments and might have missed some spots17:42
mordredmorgan: that's a good point - do you think we should include user_id in the request?17:42
morgancmurphy: you did good.17:42
mordredayoung: kk - yah- I think we can totally do that17:42
morganmordred: i almost think we should17:42
mordredmorgan: lemme take a quick stab at that17:43
morganmordred: this comment and thought was not meant to de-rail the spec though17:43
ayoungmordred, if I create an app-credential, and then my user gets deleted, what should happen to the app cred?17:43
morganmordred: if it's painful... we can punt that17:43
morganayoung: deleted17:43
mordredmorgan: I'll do it as a follow up patch so we can discuss it separately17:43
morganmordred: ++17:43
lbragstadayoung: it stays around from what i can tell17:43
mordredayoung, morgan : no- it stays around17:43
morgancan it be used to auth still?17:43
mordredthe app credential is only associated wiht a user at th emoment of creation, after that its lifecycle is independent17:43
lbragstadthe reason was because that behavior it the same as using a regular user17:44
mordredthis is one of the primary use cases17:44
* lbragstad gets popcorn17:44
morganok, i need to re-review the spec with a totally different mindset17:44
morganthis is going to cause a ton of weirdness and issues in audit trails, etc17:44
mordredso - it was also suggested that DELETE /user get a flag "delete all credentials for this user"17:44
morganunless you're creating an implicit user17:44
morganthat is part of the app-cred17:45
*** aojea has joined #openstack-keystone17:45
morgani always read the proposal as the same thing as google application-specific-passwords are17:45
ayoungmordred, so, how are app creds managed?17:45
mordredmorgan: that's been my assumption - that we'd be creating an implicit lightweight user - but I could be wrong about htat from an impl perspective17:45
ayoungmordred, implicit light weight user is ok, But if you use trusts, you have a better admin setup17:45
morganuser has an alternative mechanism for authing for a specific app (like thunderbird, if it isn't 2fa aware)17:45
morganif the user is deleted, the app-password no longer works, the user is dead.17:46
ayoungthat lightweigh user can only do the things that I can do, if I create the app cred17:46
mordredyah. that's a thing people want to avoid17:46
ayoungotherwise, much wierdness ensues17:46
mordredbecause it's a nighmare for teasm17:46
cmurphyone of the main use cases was keeping automation running even if the creator gets fired17:46
ayoungIf you as an admin take away a role from me, but I have app creds (where I17:46
openstackmorgan: Error: "!" is not a valid command.17:46
ayoungI've kep the passwrod cuz I'm sneaky) I still ahve that elelvated priv17:46
morganyeah that is bad news17:47
ayoungmorgan, now go and read the "unified dlegation" spec and much will be come clear17:47
* ayoung misses amakarov17:47
morganayoung: i've already read it a ton.17:47
ayoungyeah but once again I mean mordred17:47
mordredmorgan: maybe instead what we should do is make DELETE /user delete creds by default, but add a flag which is "do not delete app creds"17:48
mordredso that people for whom the ability is important can do so, but htey have to opt-in17:48
morganmordred: i have to spend some time on this part of it17:48
ayoungSo, there are two basic implementations, and I think we shouild explicitly allow both:17:49
lbragstadwhat should happen is at user deletion a prompt comes up and requires the app credential to be owned by someone else17:49
ayoung1.  a user can make an app-cred and that uses a trust17:49
ayounguser goes away, app cred is useless17:49
ayoung2. an admin-type user can make an app-cred and that uses a role assignment17:49
ayoungadmin user goes away, app-cred is still good17:49
mordredno. that's not good enough17:49
ayoungmake it a flag17:50
mordredif you only allow a admin to do 2, the feature is broken17:50
mordred2 is an essential end-user feature17:50
ayoungmordred, "admin" just means "someone with a higher role than Member"17:50
mordred2 is an essential Member feature17:50
ayoungmordred, and this is why I want to fix RBAC17:50
ayoungyou can't do any of this without decent RBAC17:50
* ayoung goes off to privatly sob for a moment17:51
mordredyou can totally do all of this right now as described in the spec17:51
mordredand it's FINE for people17:51
* ayoung comes back with eyes puffy and face strangely clean17:51
mordredwe can make user deletion delete app creds by default17:51
mordredas long as there is an escape valve for that some how17:51
mordredbecause otherwise this has the same limitations as oauth that make ops teams using oauth web-services cry17:52
*** ducttape_ has quit IRC17:52
ayoungmordred, make it a flag on the app-cred, and we can debate the implementation17:52
mordredI was just thinking the same thing17:52
ayoungI'm OK with both 1 and 2 being supported17:52
morganayoung: yes. that works.17:52
mordred"this is an app-cred that needs to persist"17:52
morgani want to be very careful about app-creds that continue after a user that created it disappears17:53
mordredand then we could combine that with lbragstad's idea above ...17:53
lbragstadso - it's a flag that either tightly couples the user to the app cred or not17:53
ayoungjust some way of making it a special thing to ask for persistant ones.  And that is what needs decent RBAC.  Because otherwise whayt you are going to have is deployments where ONLY admins can do ANY app cred17:53
morganadmin-specific/explicitly flagged is fine17:53
mordredif an admin goes to delete a user that has a persistent app cred associated17:53
ayounglbragstad, ++17:53
morganayoung: ++17:53
mordredthe admin either has to force-remove or provide a new user owner17:53
ayoungmordred, nah17:53
morganmordred: i would go as far as to make a special user for persistent ones and that user cannot be deleted w/o clearing app-creds17:53
cmurphyas soon as the user creates it, they're going to put the id and secret in some config file and it will be known by the whole project team17:53
morganayoung: ^17:54
ayoungmordred, if the app cred is persistant, it lasts beyond the user that created it17:54
lbragstadi don't think it makes sense to just have app creds floating around17:54
mordredmorgan: but if we do that- it's the same security hole you're concerned about17:54
morgani would want to decouple persistent ones from any specific user.17:54
lbragstadprocess tells me that if a user leaves or is deletes, their app creds should get new ownership17:54
ayoungwe can swtich on policy who is allowed to make an persistant app cred, so it is a deployers decision17:54
lbragstadis deleted*17:54
morganayoung: that is fair.17:54
morganmordred: it should be policy to allow/disallow creation of persistent creds (even if that is admin)17:55
ayoungimplementation wise, I would always make an app-cred a light weight users.  the app-cred record would indicate whether it should be a trust or a role assignemt to map to user-based vs persistent17:55
morganayoung: ok that is fine.17:55
morganayoung: impl detail aside. concepts lets work on that17:55
morganmordred: so. there HAS to be a way to prevent normal users from creating a persistent app-cred that persists beyond their user account17:56
ayoungmordred, in general, a user should not be able to provide an end-run to getting canned from their job17:56
mordredmorgan: I strongly disagree. there needs to be a way for an admin to delete persistent app creds when they delete a user17:56
mordredthat's the important bit17:56
morganif i have vexxhost account, and i create an app-cred, they delete my user, they shouldn't need to worry if any creds continue to exist17:56
ayoungmordred, I think that can be done by providing "list-app-cred-for user | xargs delete app-cred" type behavior17:56
mordredwell, in that case, they'll be deleting your project17:56
mordredayoung: YES17:57
morgannot nessicarily17:57
morganwhat if i'm a subuser not the owner.17:57
ayoungmight need to know the user-id though17:57
ayoungif we delete the user record, might not be a way to look up by id17:57
morganand the subuser is deleted.17:57
morganas an account owner i don't want to guess/have to chase this down17:57
mordredmorgan: but yes - what if the default behavior of user deletion imploies list-app-cred-for user | xargs delete app-cred17:57
mordredso delete does what you expect17:57
mordredand there is no worries17:58
ayoungthose would be the non-persistnat ones, mordred17:58
mordredbut - you can optionally delete a user and _not_ delete its app creds17:58
morganso you're saying add new flags/capabilities to delete-user?17:58
lbragstadbut the valve you talked about allows the opposite for a privileged individual17:58
mordredmorgan: yes17:58
morgani really would rather make app-creds that persist explicitly opt-in for that cred17:58
mordredsure. I'm fine with that bit17:58
morganand something that can be controlled.17:58
cmurphyonce the app cred is created it will get used in automation and the cat is out of the bag, it doesn't matter who created it or what happens to them17:59
mordredbut not that bit17:59
lbragstadwhat happens when we're dealing with application creds for a federated user?17:59
mordredI dont' want to implement a feature that nobody will be able to actually use because it'll get disabled/turned-off17:59
ayoungwould be nice to be able to re-enable an app cred or "persitify" one that is user-linked17:59
morganmordred: i have to -1 this spec at this point based upon this, and near a -2 (not yet)17:59
ayoungDufenshmirtz:  I call this my Persistenator!17:59
morgani'm sorry, this is treading on scary grounds.17:59
mordredmorgan: that's fine - I think we can figure it out - we seem to all at least understand the use case now :)18:00
ayoungyeah, removing my +218:00
morgani'm almost inclined to say no persistent app-creds that live beyond a user18:00
morganso if you need one, get a user and allow admins to create creds attached to another user18:00
lbragstadok - so maybe we need to back up a bit18:00
morgans/admin/project admin/18:00
morganthe base concept of app-cred is good18:00
morganlets start there18:01
morganreally. the sticking point is persistence beyond user lifecycl18:01
lbragstadnot thinking about app credentials any more, how would we ideally solve the issue of a user setting up a bunch of stuff in a project, leaving, and having that stuff still work?18:01
ayoungdefault for an app cred is a delegation from a user.18:01
* mordred now goes off to cry in the corner18:01
morganlbragstad: you don't want that.18:01
ayoungupgraded app cred is an explicit role assignment18:01
morganyou REALY don't want that18:01
morganas a default general thing18:02
lbragstadmorgan: that's the question that burned a forum session in boston :)18:02
morganyou want the ability to specifically allow it in *some* cases18:02
ayounglbragstad, they should create a service user, assign roles to that service user and then go away18:02
ayoungif you are worried about that service user having too much power located in one place18:02
lbragstadbut - that doesn't get us away from having to put passwords in configuration files18:02
morganneither really does this18:03
ayoungthen that sercvice user creates a bunch of these trust-like app-creds18:03
morganthis *is* a password18:03
cmurphythis is better because these can be rotated, passwords can't18:03
lbragstadit is - but the case made was that it doesn't expose password conventions for other service users in the deployment18:03
mordredmorgan: ok. I can live with starting at a point where persistent creds are an opt-in/must-be-enabled feature18:03
lbragstadcmurphy: that too18:03
mordredbecause the cred rotation and being able to make these outside of what your federated backend ar eht emost importnat things18:03
morganmordred: so, lets start with no persistence beyond user lifecycle. i like everything about app-creds besides that18:04
ayoungmordred, the ability to have an entity with permissions beyond the lifespan of the origianl user is the ability to create a user.  No matter what we call it.18:04
morganrotation, etc are solid18:04
morganwe can look at persistence after and how to address it securely18:04
ayoungAnd that user can either have role assignemnets, which persist, or get roles via a trust18:04
morganadding capabilities to an API is easy.18:04
morganremoving is ... lets just say not doable18:04
mordredmorgan: awesome. I'll rev real quick18:04
mordredmorgan: I'm going to leave a future-looking note about the use-case desire18:05
mordredsimilar to the one about api exclusions18:05
morganand if needed we can implement something that clearly bundles in the app-creds to a common place or whatever within a project if it needs to persist18:05
mordredmorgan: should we also add "explicit user_id at creation time"?18:05
morganmordred: i personally like that18:06
mordredcool - will do18:06
morganbut i wont make it a sticking point either way18:06
lbragstaddoesn't that come from the request?18:06
morganlbragstad: he's offering a "hey i am admin X and want to create this for user Y"18:06
lbragstadwhy would you want to specify that, i feel like that should come from the token being used to create the application cred18:06
lbragstadit that going to be isolated as an admin only thing?18:07
morganthat should be18:07
lbragstadok - that seems like the right thing to do if we end up supporting that18:07
morganit could (in theory) solve the issue of long-lived creds, service user-wise.18:07
morganbut it should be tightly controlled.18:08
morganif it is not specified it comes from the request (default behavior)18:09
lbragstadyeah - only an admin should be able to specify a user id18:09
lbragstadand if an admin isn't making that request it should come from the token used to create the app cred18:09
morgananyway. i think we unblocked the spec.18:09
lbragstadso -18:09
lbragstadto recap18:09
morganwe narrowed the scope a little, but in the name of security18:10
lbragstadwe not including api access lists18:10
morgan++ that is dependant on future code18:10
lbragstadand we not making it so app creds can outlive the user that created them18:10
morganthat discussion will come as a followup once the base feature is implemented18:11
lbragstadso - the current proposal will still provide better rotation of passwords18:11
morgan"can we do it securely, and how do we do that"18:11
lbragstadand no password conventions in configuration files18:11
morganno standard user-password18:11
lbragstadcmurphy: ayoung mordred how do you all feel about it?18:12
* mordred reads18:12
ayoungfeel about what?18:12
lbragstadthe summary I just posted &18:12
ayoungjust processing...18:12
lbragstadloading... loading... loading18:13
mordredyah. wfm18:13
morganmordred: sorry to throw a monkey wrench in it. but some things are big flags.18:13
ayounglbragstad, what do you mean by " if an admin isn't making that request it should come from the token used to create the app cred"  I assume you mean that it is tied to the lifespan of the user that requested it18:14
morganayoung: mordred is looking to add a "if admin, can make an app cred on the behalf of another user"18:14
lbragstadyeah - i don't want another user that isn't an admin creating app creds tied to my user account18:14
lbragstadthat seems like a privileged case that should be available to everyone18:15
morganayoung: if !admin or !not_user_id_in_request, it pulls from the token18:15
morgan(the requesting user)18:15
lbragstadmorgan: more like if !admin and user not in request, pull from the token18:15 you guys are giving me PTSD to the trust discussion18:15
ayoungso back to what I said before:18:16
lbragstadwouldn't that be a separate api call/policy check based on the things in the payload of the request?18:16
ayoungan app cred is a light weight user18:16
morgansure we could.18:16
morganmordred: hey, cna we drop the user_id specification too18:16
morganbefore you push the rev18:17
morganlets circle up on that later as well18:17
morganjust to avoid wedging the spec18:17
ayoungwe provide a flage which will be used to determine if that app cred is persistant (maps to a role assignemdn) or tied to a user (maps to a trust)18:17
morgan^ ayoung, lbragstad18:17
morganagain, adding to an API is easy.18:17
morganso to begin with, it should always be the requesting user18:17
ayoungan admin creating an app cred tied to a user other than himself is like an admin creating a trust for another user.18:18
morganwe will explore specifying a different user and/or persisting beyond user lifecycle after the base functionality is done.18:18
morganlets just nix that for now and discuss specifics independently18:18
morganayoung: ^18:18
ayoungnot something I particularly like, but we see Heat do that all the time.  Just, Heat uses the token that the user gave to Heat to create the trust18:18
morgani don't wnat to wedge this over a detail like that right now18:18
openstackgerritMonty Taylor proposed openstack/keystone-specs master: Application Credentials for application authn
mordredmorgan: oh - sorry - didn't see that- yes, I can re-remove it18:19
morganmordred: sorry, was trying to save you re-revving it18:19
lbragstadthe thing that worries me is that the policy/api changes based on the user calling it and the body of the request18:19
morganmordred: np, just to isolate that bit (we can add that in a followup that is not tied to base functionality)18:19
morganmordred: or create a new API if it is easier.18:20
morganmordred: just trying to make sure we can easily +2/land this spec18:20
samueldmqcmurphy:  mordred: I just left a couple of comments/questions on PS1918:20
samueldmq(mordred was too quick and submitted PS20)18:20
ayounglbragstad, I don't love that either ,but it is the same kind of thing we have to deal with the actions API.  We know how to do that18:20
morgani think we unblocked the major sticking points ayoung18:26
morganwe can follow up in not-this-release with addtional capabilities and spend time makiung sure they are right18:26
morganbut the core of rotaable, limited scope "creds"18:27
morganthat is good.18:27
mordredok. I've gota few more updates based on samueldmq's questions (mostly just adding clarifying sentences)18:34
openstackgerritMonty Taylor proposed openstack/keystone-specs master: Application Credentials for application authn
samueldmqaha so I had good questions18:35
morganmordred: nice18:39
ayounglbragstad, so, on RBAC in middleware, if the spec is not approved, can the implementation get merged tagged as experimental?18:39
lbragstadayoung:  i had comments on the specs - not sure if they are still there though18:39
ayounglbragstad, regardless.  I am assuming we are not going to resolve those before spec freeze18:40
ayoungI'd rather get the implemenation out there for people to use, but disabled by default, experiemantal, etc18:40
ayoungand all the caveats of "we are going to break this, don't cry when we do"18:40
lbragstadayoung: what about a feature branch?18:40
ayounglbragstad, nope18:41
lbragstadmorgan: have we ever used a feature branch before?18:41
ayounglbragstad, does not fall in line with any of the workflows I use18:41
lbragstadayoung: it would get you what you want, right?18:43
morganfeature branches were used for fernet airi18:46
morganbut otherwise not really18:46
lbragstadyeah - that was a branch of my keystone fork - but similar concept18:46
*** ducttape_ has joined #openstack-keystone18:51
samueldmqmordred: final questions in the spec18:53
samueldmqthanks for the answers on my previous questions18:53
morganmordred: commented inline18:59
morganthe only real question (and could be a followup) do we want to make the POST return {"application_credential": { ... }, "application_credential_secret": <secret> }, instead of embedding secret in "application_credential", so "app_cred" mirrors what is given in a GET.19:00
morganmordred: still +219:00
*** rderose has quit IRC19:03
*** aojea has quit IRC19:05
*** dikonoor has quit IRC19:13
mordredmorgan: I'd be fine with that19:13
morganmordred: i left a comment, but +2'd the spec19:14
morganit can be done in a follow up19:14
morganif folks like it better19:14
lbragstadstable backport reviews
lbragstadand stable newton but i'm not sure it's applicable
*** aojea has joined #openstack-keystone19:20
openstackgerritMerged openstack/keystone-specs master: Application Credentials for application authn
samueldmqmordred: ^ well done :)19:22
*** aojea has quit IRC19:25
openstackgerritMonty Taylor proposed openstack/keystone-specs master: Update a few nits in the application credentials spec
mordredsamueldmq, cmurphy, morgan, lbragstad, ayoung: yay thanks!!!!19:26
*** nishaYadav has quit IRC19:29
cmurphyanyone want to review and for me? (and also please add keystone-tempest-plugin to your watchlists)19:47
lbragstad would be a good bug to fix in case anyone is looking for one to work on19:49
openstackLaunchpad bug 1696308 in OpenStack Identity (keystone) "list revoked tokens API returns 500 InternalServerError" [High,Triaged]19:49
bretonlbragstad: i thought this error is due to pki_setup not being run19:53
lbragstadbreton: it is - but i'm not sure we should return a 500 in the event it isn't run19:54
lbragstadcould we make that better?19:54
bretonlbragstad: what will fernet return if there are no keys?19:54
*** spzala has quit IRC19:54
lbragstadbreton: ah - that's fair19:55
bretoni would probably give it wishlist priority :p19:55
bretonor even "won't fix"19:56
bretoni think we didn't even fully delete PKI stuff because of this19:56
lbragstadbreton: yeah - i think that was because it would have been a backwards incompatible api change19:57
lbragstadto rip out the api completely19:57
lbragstadbreton: better?
openstackLaunchpad bug 1696308 in OpenStack Identity (keystone) "list revoked tokens API returns 500 InternalServerError" [Wishlist,Triaged]19:58
samueldmqcmurphy: neat, approved20:05
cmurphyty samueldmq gagehugo lbragstad20:05
cmurphysamueldmq: re lxml it looks like the unit tests needs it20:09
*** ducttap__ has joined #openstack-keystone20:10
samueldmqcmurphy: ah okay :(20:11
samueldmqactually :) it's good we test things in our unit tests too20:11
cmurphylol yes20:12
*** ducttape_ has quit IRC20:13
*** thorst_afk has quit IRC20:18
*** thorst_afk has joined #openstack-keystone20:20
*** aojea has joined #openstack-keystone20:21
*** thorst_afk has quit IRC20:25
*** ducttap__ has quit IRC20:27
*** spzala has joined #openstack-keystone20:28
*** edmondsw has quit IRC20:28
*** phalmos has quit IRC20:30
*** ducttape_ has joined #openstack-keystone20:34
openstackgerritMerged openstack/keystone-tempest-plugin master: Cleanup cookiecutter defaults
openstackgerritMerged openstack/keystone-tempest-plugin master: Add lxml to requirements.txt
openstackgerritOpenStack Proposal Bot proposed openstack/keystone master: Updated from global requirements
*** thorst_afk has joined #openstack-keystone20:39
*** thorst_afk has quit IRC20:43
*** spilla has quit IRC20:47
*** edmondsw has joined #openstack-keystone21:35
*** raildo has quit IRC21:39
*** edmondsw has quit IRC21:40
*** chlong has quit IRC21:58
*** dave-mccowan has quit IRC22:06
*** dave-mccowan has joined #openstack-keystone22:07
*** rcernin has quit IRC22:19
*** ducttape_ has quit IRC22:21
*** davechen has quit IRC22:23
*** davechen has joined #openstack-keystone22:23
*** gagehugo has quit IRC22:25
lbragstadmorgan: i'm getting a failure locally with the keystone tests saying the bcrypt needs to be installed22:26
lbragstadmorgan: how is that not failing in the gate?22:27
*** ducttape_ has joined #openstack-keystone22:27
morganlbragstad: uhm.22:27
morganlbragstad: old venv?22:27
lbragstadi just rebuilt it22:27
morganit's part of rquirements now, or should be iirc22:27
lbragstadmorgan: ++ yeah, it's part of requirements22:27
lbragstadbut i'm wondering if it needs to be in ?22:28
morganboth are installe22:28
morgandid you rebuild your venv then cvheckout master?22:28
lbragstadmaybe? let me try again22:29
lbragstadit's friday - my fingers are on auto-pilot22:29
lbragstadso that *is* a possibility22:29
*** ducttape_ has quit IRC22:32
lbragstadbecause both requirements and test-requirements get installed for tests, right?22:33
*** aojea has quit IRC22:33
*** aojea has joined #openstack-keystone22:34
*** r-daneel has quit IRC22:34
*** piliman974 has quit IRC22:39
*** aojea has quit IRC22:39
*** piliman974 has joined #openstack-keystone22:40
*** pnavarro has quit IRC22:42
*** catintheroof has quit IRC22:42
openstackgerritLance Bragstad proposed openstack/keystone master: Flag GET APIs that need corresponding HEAD API
openstackgerritLance Bragstad proposed openstack/keystone master: Add HEAD APIs to federated API
*** dougshelley66 has joined #openstack-keystone22:59
morganlbragstad: yes23:06
*** piliman974 has quit IRC23:07
*** aojea has joined #openstack-keystone23:35
*** aojea has quit IRC23:40
*** piliman974 has joined #openstack-keystone23:58

Generated by 2.15.3 by Marius Gedminas - find it at!