16:00:39 #startmeeting keystone 16:00:40 Meeting started Tue Dec 4 16:00:39 2018 UTC and is due to finish in 60 minutes. The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:41 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:43 The meeting name has been set to 'keystone' 16:00:46 o/ 16:00:46 #link https://etherpad.openstack.org/p/keystone-weekly-meeting 16:00:49 agenda ^ 16:00:50 o/ 16:01:42 o/ 16:01:52 o/ 16:01:52 we'll give folks a minute or two 16:01:59 * kmalloc drinks coffee 16:02:11 o/ 16:03:56 alright 16:04:13 #topic Welcome Outreachy Interns 16:04:16 cmurphy o/ 16:04:16 o/ 16:04:18 hello 16:04:33 So for this outreachy round we have two interns, erus and imus 16:04:38 please give them a warm welcome 16:04:42 awesome! 16:04:47 hi erus and imus 16:04:59 hi 16:05:00 erus will be working on some federation improvements and imus will be working on the api unit test refactor 16:05:03 welcome~ 16:05:08 hey! 16:05:09 woohoo! great to have you all 16:05:14 Hi everyone thanks o/ 16:05:14 Thanks 16:05:16 welcome :) 16:05:19 * kmalloc cheers for imus and erus 16:05:38 :) 16:05:48 that's about all I had for that, glad to have erus and imus on board :) 16:06:13 Glad to have the opportunity :) 16:06:19 imus erus i'm located in utc-6, don't hesitate to reach out if you have questions 16:06:22 Thanks cmurphy 16:06:45 we have pretty good coverage 16:06:47 erus: imus: by the way lbragstad is the Project Technical Lead so he knows everything 16:06:52 false 16:06:56 ;) 16:07:02 i "pretend" to know everything 16:07:03 Haha 16:07:21 but i end up leaning on everyone else when i'm wrong ;) 16:07:22 I'm in utc-3 16:07:33 XD 16:07:44 erus cool - that sounds good 16:07:48 i'll probably be awake later than most folks, hm.. Pacific is UTC-8 now? 16:07:56 so i'll be around probably later than most folks. 16:08:02 Cool 16:08:12 also lbragstad does know everything 16:08:14 :P 16:08:24 I'm always awake too xd 16:08:50 So good to have a mixed utc team :) 16:09:00 * kmalloc is just trying to make everyone to not look at git blame and see "Morgan" name on everything 16:09:32 alright - few more things on the agenda 16:09:40 #topic Summit recap 16:09:57 yeah. it's a great team. i'm super happy we got to add both of you to it (at least for now! hopefully longer after outreachy finishes this cycle) 16:10:17 in case you haven't noticed, the foundation has updated all the recorded content from the summit 16:10:20 Yeah it would be great! 16:10:38 happy to be here and yes hopefully for longer 16:10:54 i've put together a short summary of keystone and TC related content https://www.lbragstad.com/blog/openstack-summit-berlin-recap 16:11:00 the thumbnail for the talk ayoung, knikolla, and I did is perfect :P 16:11:20 does anyone else know of recaps floating around? 16:11:25 can't imagine it happening accidentally 16:11:29 I didn't do one this time 16:11:42 ack - just double checking 16:12:28 #topic Outstanding Reviews 16:12:31 * kmalloc didn't do a keystone IDP recap... but next summit/ptg expects to. 16:12:38 since we'll be further along 16:12:43 kmalloc good idea 16:12:58 alright - does anyone have patches up for review that they need eyes on? 16:13:33 specification reviews included 16:14:02 https://review.openstack.org/615190 16:14:05 https://review.openstack.org/#/c/605043/ 16:14:21 https://review.openstack.org/615847 16:14:36 poor ldappool gets no love 16:14:38 cmurphy: +2/A on ldappool 16:14:48 done 16:14:58 the keystoneauth rate-limit patch needs eyes 16:15:14 it has a functional cross-over test with SDK, we should eventually have a first-party in-tree test too 16:15:23 but i'm ok with it as long as we have eyes on the code 16:15:26 also it's not ready yet but i wouldn't mind feedback on https://review.openstack.org/615384 16:15:48 cmurphy ah - i was going to start looking at that earlier today, but saw it was still WIP 16:15:58 kmalloc ack - i can take a look today 16:16:37 cmurphy: the guide is awesome, I'm waiting for the TODO part. :) 16:16:55 :) 16:17:03 need to find some extra time to get back to it 16:17:15 it's amazing how there always seems to be no time 16:17:23 fact 16:17:39 any other reviews people want to draw attention to? 16:18:36 #link https://review.openstack.org/#/c/614195/ will unblock some patches for us in keystone 16:18:52 same iwth 16:18:54 #link https://review.openstack.org/#/c/611443/ 16:19:46 i also re-spun all the patches for implementing default roles late last week 16:19:54 those should be passing and ready for some eyes 16:19:57 #link https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:implement-default-roles 16:20:16 and some patches to cleanup the policy.v3cloudsample.json 16:20:21 #link https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:clean-up-v3-cloud-sample 16:21:34 alright - moving on 16:21:48 #topic Renewable Application Credentials 16:21:50 knikolla o/ 16:21:54 o/ 16:21:59 spec is up 16:22:01 #link https://review.openstack.org/#/c/604201/ 16:22:06 hooray! 16:22:12 i have reworked it a bit from the discussion we had last week 16:22:16 * kmalloc quickly +2/+As it before anyone can -1 it :P 16:22:25 mainly i kept one list of roles instead of two 16:22:25 * kmalloc adds this to a list to review today 16:22:42 knikolla: ok, i'm interested in how that ends up working. 16:22:52 and added `last_renewed` and `identity_provider` 16:22:56 to the app cred model 16:22:58 hm. 16:23:20 but how does it work with knowing if a role is conferred via the IDP vs concretely on creation? 16:23:24 i missed that discussion last week, but i'll take a pass at the spec before i start firing off questions 16:23:25 the entire app cred deactivates when it's not renewed. 16:23:26 so we know what roles might change. 16:23:50 to prevent users from indefinitely logging in even though their account in the idp has been disabled 16:24:00 (this one was influenced by our cloud admin) 16:24:01 or do we not care and just look when the IDP conferred roles change to see if the app cred's roles are valid? 16:24:14 so if a role changes and no longer available just invalidate? 16:24:18 on renew we expand the group membership and see if it has all the roles 16:24:23 if it doesn't. fail renew 16:24:28 yup 16:24:30 ok. 16:24:51 on concrete roles, the current logic disables the app cred already if i'm not mistaked. 16:24:53 and it is still possible to create an unexpired/non-renewable app cred based upon concrete roles? 16:24:56 when a concrete role is removed 16:25:07 yes, if not using a federated token 16:25:12 iirc - that's handled with a callback 16:25:17 if federated token, enforce renewal 16:25:23 and it looks like you are limiting an app cred to roles from a single IDP 16:25:27 just from your description 16:25:36 because roles are in the token 16:25:40 since the app-cred (not the roles) are linked to the IDP 16:25:40 through groups 16:25:51 * kmalloc is ok with this. 16:25:54 and user will present the token to get an app cred 16:26:02 can't really have a token with roles from multiple idps 16:26:12 and the IDP still configures the refresh window/period then 16:26:22 knikolla: true. 16:26:34 we might need to revisit that with full IDP/autoprovision 16:26:40 yes, there is a default ttl for backwards compat with existing idps in the db, configurable 16:26:41 but for now, this is a good starting place 16:26:51 knikolla: perfect. 16:27:34 also the idp of the app cred changes if the user comes in through a different idp to renew but has same roles 16:27:39 and the ttl changes based on the last idp to renew 16:27:50 hm. 16:28:21 so, a new app cred is implicitly created if a renew is done via a different idp? 16:28:51 or just idp updatE? 16:28:54 kmalloc: no, just the idp associated with it changes for calculating the expiration. 16:28:55 because that sounds... broken 16:29:14 i'll review the spec 16:29:16 i want to think on that 16:29:35 i am not sure i want to see app-creds change owning idp. $securityconcerns$ 16:29:50 ++, i don't feel strongly about it. 16:29:56 this was mostly for UX. 16:30:07 the roles are immutable either way. 16:30:13 i might ask a lot more ux related questions on that front 16:30:18 can't add or remove after expiration. 16:30:24 creation* 16:30:28 but i have security concerns, i'll comment on the spec 16:30:33 ok, cool. 16:30:35 can be not-in-meeting :) 16:30:43 i'll be around office hours for all questions 16:30:48 * kmalloc nods. 16:30:59 thanks knikolla 16:31:04 anything else on this? 16:32:13 i think that's all i had, i'll be around in the office hours to discuss in more detail. 16:32:18 please review the spec 16:32:36 sounds good 16:32:40 #topic admin role deletion 16:32:42 cmurphy again 16:32:45 hi 16:33:08 so a customer of ours had an outage where an inexperienced administrator accidentally deleted the admin role via horizon 16:33:22 eek 16:33:29 like... EEEEEK 16:33:29 it's pretty destructive since usually service users use the admin role too 16:33:54 hmmm... do we want to take the next steps and make default roles immutable? 16:33:58 knikolla: no. 16:34:05 so my team mate was inquiring if this is something we can deal with upstream somehow 16:34:19 thought so 16:34:24 i could see a "resource option" for immutable though 16:34:32 cmurphy is there a particular solution your team is looking for? 16:34:40 like a "lock" 16:34:46 but not inherently immutable 16:34:53 as in, something that could be toggled. 16:34:54 are they looking for a "confirm delete" workflow? 16:34:58 lbragstad: no we're not advocating anything specific, just make it harder to footgun like this 16:35:27 i suggested maybe just make a "are you sure?" thing in horizon but that doesn't help if you accidentally do this with the cli 16:35:36 yeah... 16:35:37 which is a likely scenario in bad scripts 16:36:17 i think a resource option with an immutable flag (or locked, whatever UX is best) would be great... this is a lot mroe work though since horizon doesn't understand Resource Options 16:36:44 also, *wince* soft delete(s) in general make recovery easier. 16:37:30 hmm 16:37:40 if we implement a resource option for roles, i'd like to see the "cannot be changed/deleted" added to other resources as well via the same mechanism 16:38:08 to be consistent with other resources, we could implement enabled/disabled for roles and have the default behavior for deleting a role be to disable it first 16:38:22 lbragstad: the problem with that is it's not backwards compatible 16:38:31 cmurphy: ++ 16:38:34 true 16:38:42 we could add an opt-in "this is locked" 16:38:48 we cannot change basic delete behavior 16:38:51 (in v3) 16:38:59 but adding it as a resource option might work, but it would only be useful if the default behavior of bootstrap is to set that flag 16:39:11 cmurphy: i'm ok with making that the default behavior 16:39:18 or at least bootstrap to add that as an option 16:39:25 --make-created-roles-immutable 16:39:25 we can also add keystone doctor checks 16:39:37 your admin role is not locked, an admin might accidentally delete it 16:39:39 for the transition period 16:39:47 so 1) add Resource Option 16:40:00 2) opt-in via bootstrap (doctor check saying "OMG LCOK THIS") 16:40:08 3) default behavior in bootstrap to set flag 16:40:15 with an opt-out flag. 16:40:16 ++ 16:40:27 over... a release barrier between 2/3 16:40:35 sounds good to me 16:40:44 cool - does someone want to write this up? 16:40:47 i'll bring this back to my teammate to see what they think 16:40:51 i can write it up as a backlog spec 16:40:56 cmurphy: ++ 16:40:56 awesome 16:40:57 probably won't have time to implement it this cycle 16:41:09 how high of a priority is this for your team? 16:41:10 we have some need to do resource opptions for projects this cycle 16:41:21 so it would be not a lot of work to add that construct to roles 16:41:25 at the same time. 16:41:36 lbragstad: well the customer recovered from it and the admin is now educated so not very high priority any more :) 16:41:55 ack 16:42:09 i also would like to lean on this before we expose the root-domain, so we can limit update and auto-set the immutable flag otherwise 16:42:17 ++ 16:42:19 at least until the next customer hits it 16:42:24 rather than needing to exempt it from delete/update/etc apis 16:42:37 makes sense 16:43:06 cool - so long as we get the approach written down, that'll be a good start 16:43:29 ++ 16:43:35 and later today (once I get my new monitor) i can start hacking on code/specs again for things this cycle 16:43:43 anything else here? 16:43:48 i can lump in resource option additions for roles 16:43:57 and we can add the immutable work as a followup 16:44:05 kmalloc: uuu new monitor, nice 16:44:20 * kmalloc is planning to expand resource options as a default for all resources 16:44:26 even if it's unused. 16:44:34 silly not to 16:44:59 that way it's trivial to add this type of stuff when needed. 16:45:25 * kmalloc is done with this topic. 16:45:34 #topic identity provider proxy diagram 16:45:42 ok so this is VERY rough 16:45:43 and early on 16:45:49 https://usercontent.irccloud-cdn.com/file/Au4e3DXb/Keystone%20IDP%20(initial)%20Diagram.png 16:46:15 this will get massively refined and have a DB schema diagram added as well as a UI site-map-y target diagram 16:46:20 #link https://usercontent.irccloud-cdn.com/file/Au4e3DXb/Keystone%20IDP%20(initial)%20Diagram.png IdP diagram 16:46:33 and this one will be split into a single diagram per-workflow 16:46:41 it doesn't show autoprovisioning 16:46:53 with that said, this is starting to show what the target of Keystone should be 16:47:05 and takes an initial stab at data-flows. 16:47:49 please forgive the fact i did this at like... 3am in the morning 16:47:59 i like the icons 16:48:14 once i iterate a bit more we'll land this in a common/official place 16:48:14 suitcase == assignment 16:48:18 cmurphy: :) 16:48:33 draw.io is pretty badass with the icons it has 16:48:59 and i'll render this as an .svg for our official space so we can iterate on it as things change within keystone 16:49:53 any questions/concerns.... happiness? 16:50:08 seems fairly standard federation 16:50:24 yeah. it's just trying to give us an explicit target to reference 16:50:25 what's the difference between black highlight and white highlighting in the flows? 16:50:36 lbragstad: just so you could see the different ones 16:50:39 lbragstad: grouping 16:50:54 i will split those into separate diagrams down the line 16:50:58 ok 16:51:12 so non-openstack SPs, OpenStack SPs, Keystone Crud as an SP, and JS-UI 16:51:30 those will be data flow, and indicate autoprovision where needed. 16:51:57 i hope this is helping folks see what is in my head (as early as it is) 16:52:07 and each will be it's own diagram 16:52:42 ok 16:52:58 kmalloc how do you want feedback, just pings for now? 16:53:11 devil will be in the details 16:53:30 lbragstad: yeah 16:53:50 since this is a first pass, it's just a "hey, everyone happy with the start of this direction?" 16:54:19 ok 16:54:19 i'll pick through this a bit more 16:54:26 thanks for putting this together kmalloc 16:54:29 expect it is missing most of the stuff still 16:54:31 :) 16:54:39 anything else on this? 16:54:40 it will get better with iterations 16:54:44 nothing else. i'm done 16:54:49 #topic open discussion 16:55:19 there has been a trend for people to just hold meetings in their respective IRC channels 16:55:34 how do people here feel about that? 16:55:39 -1 16:56:04 it's nice to have it in a shared channel because we tend to pull in people from other projects randomly 16:56:27 true 16:56:48 also we get enough traffic in the main channel that i think it's better to split out the meeting so that people asking questions dont' feel like they have to wait for the meeting to be over 16:57:34 ok - that's fair 16:57:55 anything else for open discussion? 16:58:09 -1 16:58:18 same reason supplied as cmurphy 16:59:15 alright - with that, we're about out of time 16:59:34 thanks for attending 16:59:46 #endmeeting