18:01:56 #startmeeting keystone 18:01:56 Meeting started Tue Mar 7 18:01:56 2017 UTC and is due to finish in 60 minutes. The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:57 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:02:00 The meeting name has been set to 'keystone' 18:02:03 ping agrebennikov, amakarov, annakoppad, antwash, ayoung, bknudson, breton, browne, chrisplo, cmurphy, davechen, dolphm, dstanek, edmondsw, edtubill, gagehugo, henrynash, hrybacki, jamielennox, jaugustine, jgrassler, knikolla, lamt, lbragstad, kbaikov, ktychkova, morgan, nishaYadav, nkinder, notmorgan, portdirect raildo, ravelar, rderose, rodrigods, roxanaghe, samueldmq, SamYaple, shaleh, spilla, srwilkers, 18:02:03 StefanPaetowJisc, stevemar, topol, shardy, ricolin 18:02:04 o/ 18:02:06 o/ 18:02:07 o/ 18:02:08 agenda #link https://etherpad.openstack.org/p/keystone-weekly-meeting 18:02:11 o/ 18:02:12 o/ 18:02:16 o/ 18:02:22 o/ 18:02:23 ehlo 18:02:26 o/ 18:02:50 we have a lot on the agenda today - so i'll get started wth announcements as folks trickle in 18:02:56 #topic Announcement: Pike deadlines 18:03:02 #link https://review.openstack.org/#/c/441999 18:03:29 I proposed our deadlines for Pike and I'm going to double check those today 18:03:41 and resolve the merge conflict 18:03:54 but I'd expect to have those cleaned up and merged sometime this week 18:04:07 o/ 18:04:20 just giving everyone a heads up so that they know what we have for a schedule in Pike as far as deadlines go 18:04:30 #topic Announcement: New release of keystoneauth today after the following merge 18:04:37 #link https://review.openstack.org/#/c/442516/ 18:04:37 #link https://review.openstack.org/#/c/442536/ 18:04:43 just for awareness 18:04:55 if there is anything folks want in the next release of ksa - let me know 18:05:09 otherwise we'll be cutting the first version for pike sometime today or tomorrow 18:05:29 alright - on to the fun stuff 18:05:29 #topic VMT follow up from PTG 18:05:31 Followed up with a few folks from OpenStack Security that have some good information we can use to forward with VMT for identity related projects 18:05:38 those are test fixture changes btw ^ the ksa bits 18:05:39 ping michaelxin, knangia, xin9972, unrahul 18:05:52 knangia unrahul o/ 18:06:01 #link https://openstack-security.github.io/collaboration/2016/04/26/threat-analysis-process.html 18:06:01 #link https://openstack-security.github.io/collaboration/2016/01/16/threat-analysis.html 18:06:03 hey lbragstad 18:06:19 hey lbragstad 18:06:21 so michealxin won't be available today 18:06:31 unrahul knangia thanks for dropping by! 18:06:44 sure lbragstad , let us know how we may help out 18:06:58 unrahul knangia would you mind giving us a brief introduction to what you both do? 18:07:40 yup so we are both from OSIC security team, mainly working on the openstack security testing project syntribos 18:07:54 we are members of the openstack security project 18:08:04 nice 18:08:20 unrahul it sounds like you are both familiar with the VMT security analysis process as well? 18:09:17 We have participated in the initial discussions on security analysis of barbican, it was mostly driven by Rob clark and Doug chivers from the security team 18:09:41 awesome - we poked around at that document during the PTG 18:09:43 And if you guys are initiating a security analysis for keystone, I would recommend involving either of them 18:09:46 and used it as a reference 18:09:53 great.. 18:10:02 unrahul do they have irc nicks? 18:10:08 exactly, participated in barbican threat analysis, but mostly i guess, michael xin can guide us 18:10:09 yes, the goal is to get Keystoneauth, KeystoneMiddleware, and Keystone reviewed 18:10:47 yeah - we were planning on starting with keystonemiddleware (at least according to our etherpad) #link https://etherpad.openstack.org/p/pike-ptg-keystone-vmt-coverage 18:10:57 yes, hyakuhei and capnoday 18:11:00 the VMT only covers keystone server at the omment and an updated analysis is definitely in order sinc e keystone has changed a TON since it split from Nova 18:11:22 as has ksm. 18:11:29 right 18:11:43 so keystone middleware is the one that you are going to start with? 18:11:56 unrahul i think that was the initial plan 18:12:01 right notmorgan? 18:12:21 whatever was agreed to is what we are doing. :P 18:12:27 i am going to say sure ;) 18:12:46 yeah the three listed in the etherpad were the first goals I believe from the PTG 18:12:49 * notmorgan can only do so much being split in all the ways I am, so, defering to the notes taken from the meetings 18:13:02 i believe that was the action item 18:13:12 ok 18:13:28 the goal was to see if we could get ksm done first 18:13:30 and since it is a smaller code base, i think that would be a good start? 18:13:38 i'm just glad folks are taking interest in this and helping to make those of us working on the VMT lives easier. 18:13:46 ++ 18:13:57 In any case, we need to have a well defined architectural diagram to identify background information and data flow paths, trust boundaries etc. 18:14:03 i was super relieved to hear that unrahul and knangia were working on this, too 18:14:24 unrahul so it coming up with that diagram the first step? 18:14:29 So we need to have a latest architectural diagram first 18:14:31 yes lbragstad 18:14:36 unrahul cool 18:14:41 yes, the architecture diagram should be the start 18:15:07 ok - so that'd be something we as the keystone team would be on the hook for 18:15:20 we might also improve our developer docs in the process of this 18:15:29 then i assume we work on it together? 18:15:41 knikolla ++ i was just thinking about that super old keystonemiddleware arch document we have 18:16:00 And we are not actively working on the threat analysis, but yes have participated in the initial draft of barbican during our mid-cycle. We are willing to help in anyway we can, especially with michaelxin having extensive experience in the field. 18:16:39 https://openstack-security.github.io/collaboration/2016/04/26/threat-analysis-process.html 18:16:43 unrahul ok - do you need the diagram in any particular format? 18:16:48 for reference ^^ 18:17:14 Here is a sample diagram of barbican https://github.com/openstack/security-analysis/blob/master/doc/source/artifacts/barbican/newton/architecture-page.rst 18:17:50 aha 18:17:51 it was mostly done on draw.io 18:18:00 interesting 18:18:04 ah i was wondering what tool was used 18:18:14 notmorgan: draw.io 18:18:18 * notmorgan has been using ascii-flow, but draw.io is way way cooler 18:18:36 cool tool 18:19:03 A diagram such as this would enable us to identify data assets, its impact and how the system talks with the outside world 18:19:15 notmorgan: ascii-flow is indeed cool :) 18:20:12 yes, so should know the assets, its impacts, trust boundaries with th help of diagram 18:20:16 is anyone from the keystone team interested in taking a stab at updating our ksm architecture doc and doing the diagram? 18:20:43 fwiw - this would only be fore ksm initially 18:20:46 I'd be willing to help 18:21:04 gagehugo awesome - anyone else feel like tag-teaming it? 18:21:11 o/ 18:21:11 I'm not a great artist though :( 18:21:29 gagehugo that's what draw.io is for ;) 18:21:30 knikolla yeah? 18:21:40 knikolla gagehugo i'll put you both down for it then? 18:21:49 sounds good 18:21:54 sounds good 18:21:58 sweet 18:22:17 cool ! 18:22:35 #action gagehugo and knikolla to start updating keystonemiddleware architecture doc and provide knikolla and unrahul with an updated keystonemiddleware architecture diagram 18:22:45 o/ 18:22:50 #undo 18:22:51 Removing item from minutes: #action gagehugo and knikolla to start updating keystonemiddleware architecture doc and provide knikolla and unrahul with an updated keystonemiddleware architecture diagram 18:22:58 #action gagehugo and knikolla to start updating keystonemiddleware architecture doc and provide knangia and unrahul with an updated keystonemiddleware architecture diagram 18:23:41 knangia unrahul i assume once those things are done, we can start the next steps in the process 18:24:41 knangia: unrahul: which irc channel can we usually find you? 18:25:29 lbragstad: knikolla we hang out mostly in #openstack-security 18:25:36 cool 18:25:38 +1 unrahul 18:25:44 you guys are welcome to join and ping us or anyone of us there for help 18:25:59 alright, added. 18:26:02 nice - i just joined 18:26:09 great 18:26:19 awesome - well it sounds like we have a path forward 18:26:31 gagehugo knikolla thanks for being awesome and helping with this 18:26:39 As this process is going on, it is a good idea to initiate discussions with the security team, by pining hyakuhei , who is the security PTL 18:26:47 gagehugo knikolla do either of you have specific questions? 18:27:06 at the moment no 18:27:09 lbragstad: not yet 18:27:15 probably will later though 18:27:18 gagehugo knikolla ack 18:27:30 unrahul knangia do either of you have specific questions for us? 18:27:38 hyakuhei can be a great assistance 18:28:25 awesome 18:28:38 knangia: noted 18:28:51 nop, nothing as of now, may be talking with someone in barbican can give more advice on how to do the new process as well as they just finished theirs 18:29:08 not for now...probably later 18:29:11 I think redrobot is the barbican point of contact 18:29:29 unrahul that makes sense, i assume we can hash that out in #openstack-security, too? 18:30:02 yes 18:30:16 I'll put a note on next weeks agenda to keep this in the fore front 18:30:32 but I assume we'll come knocking when we have the diagram and everything ready to go 18:31:04 unrahul knangia thanks for the time, answering questions, and being willing to help out 18:31:44 lbragstad: anytime, ping us if you guys need any further help, or anything. 18:31:49 you're welcome :) glad to help 18:31:52 unrahul will do 18:31:59 will do! 18:32:17 alright - moving on 18:32:19 #topic PTG Topics 18:32:39 last meeting we parsed a bunch of back logged specs and PTG items 18:33:06 i've proposed some patches to update the keystone-specs repository accordingly 18:33:28 we only have a couple topics left 18:33:29 #topic PTG Topics: Decouple auth from API version 18:33:34 #link http://specs.openstack.org/openstack/keystone-specs/specs/keystone/backlog/decouple-auth-from-api-version.html 18:33:46 notmorgan i know we had a pretty detailed discussion about this at the PTG 18:34:24 notmorgan but since you have a better idea of how all that works, do you think the backlogged spec needs to be updated? 18:34:32 given the current state of keystone? 18:34:38 sooooo 18:34:44 i remember talking about this, but i don't remember if we were going to get it done this cycle 18:35:06 basically what needs to happen is we need to implement the new auth route for keysotne at /auth 18:35:09 dstanek i'm not sure either - but I for sure want to capture notmorgan's PoV on it 18:35:26 which takes an auth "version" or whatever we want to call it as part of the body/header/something 18:35:45 then we need to wire up /v3/auth and /v2.0/auth into the mechanism 18:35:45 the reasons for doing it seemed to make sense at the PTG and I think we should add them to the spec if we can, that way we don't lose the information 18:36:02 so when those routes are hit, it converts to the expected form and passes across internally 18:36:26 once that is done, we need to ensure ksa can talk to the new auth endpoint and know it's the new auth endpoint 18:36:42 so GET /auth would need to produce something interesting 18:36:56 it's not crazy nor super complex 18:37:09 what are the reasons? 18:37:11 it's just giving us flexability in auth without mucking with the crud interfaces 18:37:33 because iterating on /v3/auth is going to _require_ microversions and microversions for auth on the v3 interface is a terrible idea 18:37:52 it also allows us to maintain auth data if it doesn't need to change if we want to say do v4 api instead of microversions 18:37:53 because.... ? 18:37:56 this would require microversions as well, per the api guidelines 18:38:07 edmondsw: no. 18:38:38 the new guidelines are pretty strict 18:38:52 notmorgan go read https://review.openstack.org/#/c/421846 18:38:53 the guidelines are terrible if we have to put microversions on an endpoint like auth 18:39:28 they basically want to microversion any change, for interop reasons 18:39:34 microversions for CRUD interfaces is lazy and terrible. 18:39:43 but is fine because we already lost that argument 18:40:29 knikolla: then i think i need to just stop talking. 18:40:44 scuttle the spec. just microversion things 18:41:08 i thought there was discussion at the PTG that made microversions questionable 18:41:33 i mean - we already removed the microversion spec from our backlog 18:41:34 lbragstad within the keystone room... but outside of keystone microversions are winning the day 18:41:52 if we don't do microversions in keystone, moving auth is super important 18:42:00 because the headache of v2->v3 was auth 18:42:03 not the crud interface 18:42:17 the fact we tied auth to the api crud api was a big mistake in v2.0 18:42:20 and carried into v3 18:42:29 (predates everyone here except maybe dolphm) 18:43:02 if we do microversions in keystone and auth endpoint would need it too, i wont fight too hard for this 18:43:33 i'll just let the folks doing microversions handle these cases. since it'll cover it 18:43:41 * notmorgan still thinks microversions are simply a terrible idea 18:43:56 it comes down to keystone direction 18:44:09 notmorgan would you be interested in documenting the reasons for decoupling auth from versions in the spec? 18:44:18 notmorgan even if it's just a simple list? 18:44:40 right... I don't disagree about microversions being awful. If keystone wants to hold out on not doing them, I'm fine with that. But we won't get that silly tag 18:45:05 edmondsw: i'd rather keystone didn't have that tag 18:45:09 edmondsw: ++ for aiming for *not* having the tag 18:45:15 :) 18:45:20 we're special 18:45:24 lbragstad: the reasons are in the problem statement 18:45:28 we're just a bunch of rebels 18:46:01 notmorgan ok - so the spec is accurate, even with all the changes in keystone since it was proposed? 18:46:05 yep 18:46:08 s/proposed/merged to backlog/ 18:46:09 ok 18:46:10 because auth hasn't really changed 18:46:20 ok - cool 18:46:28 the only things we might modify is make /catalog a top level bit as well 18:46:31 or similar 18:46:44 sounds like we can just leave it as is then for now 18:46:48 yep. 18:47:04 onward! 18:47:05 #topic PTG Topics: Materialized Path for HMT 18:47:08 but like i said, if we're doing microversions, i just wont push hard for this and would just say might as well scuttle the spec 18:47:36 notmorgan sounds like we haven't gotten a definitive answer on that yet - but when we do i'll be sure to update accordingly 18:47:39 #link http://specs.openstack.org/openstack/keystone-specs/specs/keystone/backlog/materialize-project-hierarchy.html 18:47:55 this has been in backlog for a long time 18:48:31 i think we killed this a while ago 18:48:37 like all the code for it 18:48:56 yeah - i remember seeing an implementation for it somewhere, 18:49:00 it was -2'd and abandoned because of some reason? also no one is championing it anymore 18:49:02 it was in review for a long time/ 18:49:05 it's not a bad idea. 18:49:07 afair 18:49:14 no - it does sound useful 18:49:15 i think we may need to revisit the problem again because of limits 18:49:20 right 18:49:25 i don't remember why it was killed 18:49:35 not sure about the implementation though 18:49:48 dstanek: let's derive a new problem statement once we figure out limits 18:50:16 knikolla: there is no different in the fundamental issue 18:51:07 from a performance perspective, we'll need this at some point if we do HMT I assume 18:51:18 we simply need a more efficient way to grab hierachy info... the limits work will just dictate what we do with it 18:51:34 dstanek: understood 18:51:43 this probably isn't needed this cycle though 18:51:48 so it sounds like we need to follow up on this once we come to a more definitive conclusion of limits 18:52:34 i'd even go further to say we can follow up after we have a working poc for limits 18:52:43 then this would be an optimization 18:52:55 dstanek: ++ 18:53:13 #action keystone group to follow up on materialized path for HMT once we come to a conclusion on limits 18:53:23 works for me 18:53:35 i don't expect that to happen before Queens 18:53:40 moving on 18:53:41 #topic PTG Topics: Default Policy File 18:53:53 #link http://specs.openstack.org/openstack/keystone-specs/specs/keystone/backlog/policy-default.html 18:54:10 with all the work antwash and ravelar have been doing, I don't think this is need anymore 18:54:10 this is obsolete by policy in code right? 18:54:23 yeah - i think so 18:54:27 yep 18:54:30 yep 18:54:35 This grew out of the diesre to merge the curent ahd cloud sample approachs IIRC 18:55:00 Ah...no...that one can die 18:55:11 #action lbragstad to remove policy default spec 18:55:20 I didn;t realize it was still around. That was a vestige of the Dynamic policy effort 18:55:29 nice - that was easy 18:55:30 thanks for confirming 18:55:33 moving on 18:55:34 #topic Reviews 18:55:39 pretty sure I wrote it 18:56:01 so we have some reviews to get around to - posted them here so that folks are aware 18:56:05 password hashing in keystone: #link https://review.openstack.org/#/c/438808/ (bug: #link https://bugs.launchpad.net/keystone/+bug/1668503 ) 18:56:05 Launchpad bug 1668503 in OpenStack Identity (keystone) pike "sha512_crypt is insufficient, use pbkdf2_sha512 for password hashing" [High,In progress] - Assigned to Morgan Fainberg (mdrnstm) 18:56:09 Will need to be backported to all supported releases 18:56:13 nope 18:56:17 not being backported 18:56:28 too difficult to do w/o disruption 18:56:34 notmorgan isn't that what your note said? 18:56:42 notmorgan aha - maybe i misunderstood then 18:56:46 that is a master and forward change now 18:56:49 the note was originally that 18:56:54 it has changed post discussion in -keystone 18:56:55 ok 18:57:03 ok - cool 18:57:08 either way, we'll need to get some eyes on it 18:57:10 because it requires new config options etc 18:57:16 really is not backportable. 18:57:21 true 18:57:36 make sure it does not break LDAP 18:57:38 the ci failure it was seeing was unrelated 18:57:50 ayoung: only affects password storage 18:57:53 since ldap is non-write 18:57:54 got it 18:57:56 doesn't matter 18:58:11 couple more 18:58:12 policy in code: #link https://review.openstack.org/#/q/topic:bp/policy-in-code+status:open+project:openstack/keystone 18:58:12 oslo.policy descriptions: #link https://review.openstack.org/#/c/439070/ 18:58:16 the ci failure was testr binary/script in a non-expected location ftr 18:58:22 so, please review. 18:58:23 and finally - spec reviews 18:58:48 we have a bunch of things proposed to specs, but it looks like most either need to be abandon or updated to reflect discussions had at the PTG 18:59:30 spec proposal freeze will be in about 6 - 7 weeks 18:59:38 but that's all I have 18:59:44 thanks for coming everyone! 18:59:49 #endmeeting