18:00:28 #startmeeting keystone 18:00:29 Meeting started Tue Mar 14 18:00:28 2017 UTC and is due to finish in 60 minutes. The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:30 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:32 The meeting name has been set to 'keystone' 18:00:35 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:00:35 StefanPaetowJisc, stevemar, topol, shardy, ricolin 18:00:39 o/ 18:00:39 o/ 18:00:40 agenda #link https://etherpad.openstack.org/p/keystone-weekly-meeting 18:00:43 howdy y’all 18:00:46 0/ 18:00:48 o/ 18:00:48 o/ 18:00:49 o/ 18:00:53 o/ 18:01:08 o/ 18:01:13 o/ 18:01:33 Hey Ho, Lets Go! 18:02:22 o/ 18:03:11 alright - we have a lot on the agenda today so let's get started 18:03:15 #topic Mascot 18:03:27 i got an email last week from the foundation asking if we liked our mascot 18:03:54 we have the opportunity to make changes if we want them 18:04:01 o/ 18:04:33 I like the design 18:04:35 Heidi, from the foundation, mentioned that someone thought about incorporating a key into the shell of the turtle 18:04:49 right now - it's in the shape of a shield 18:04:50 I thought a keyhole would be more appropriate 18:05:03 * ayoung looks for early prototypes 18:05:18 ayoung: ooo i remember those prototypes 18:05:21 https://admiyo.fedorapeople.org/openstack/stoney-turtle.svg 18:05:43 * notmorgan doesn't wanna. 18:06:00 i kinda still like the Keystone Lite logo we had. 18:06:04 ftr. 18:06:18 that said, i don't feel strongly the turtle needs to change 18:06:25 notmorgan, will live forever on our jackets 18:06:51 does anyone else have things they'd like to incorporated into the logo? 18:06:52 the only mascot that i could see on a laptop of mine is the new Ironic one, fwiw. 18:07:22 s/to/to see/ 18:08:25 alright - i'll give ayoung's feedback to Heidi and if they roll a new version we can vote on it 18:08:42 #action lbragstad to give feedback to the foundation and keep team posted on outcomes 18:08:54 #topic Upstream training liaison 18:08:58 ildikov o/ 18:09:13 lbragstad: tnx 18:09:15 Hi All :) 18:09:26 ildikov and i talked about various upstream training efforts at the PTG 18:09:32 ildikov o/ 18:09:52 the plan is to have liaisons from every team 18:09:53 ildikov but i'll let her give an intro 18:10:16 both for the training and to on board new contributors in general 18:10:49 the training itself is one and a half days long, interactive and hands-on and that aims to show the first steps to the contributors 18:11:14 we are running it before every Summit, the next one will be in Boston, Saturday afternoon and Sunday 18:11:52 we are running a short survey, so students can voice their interest in contribution areas and projects 18:12:12 we would like to have coverage for the areas they are interested in on site 18:13:16 as for the liaisons, the expectation is that if they can help us with the training material and/or attending the training and help the students that would be great 18:13:39 ildikov i know dstanek expressed interest in helping 18:13:58 lbragstad: sounds great! :) 18:14:01 ildikov but i assume you wouldn't be opposed to others helping out if they are interested? 18:14:15 not at all! 18:14:31 awesome 18:14:54 ildikov you all planning on having a weekly meeting, right? 18:14:57 the current volunteers are all enthusiastic people, but we can always use more ideas and help 18:15:21 we will soon start the preparation to the Boston Summit and we will look into run weekly meetings 18:15:35 we have anew IRC channel: #openstack-university 18:15:47 ildikov are liaisons expected to be at the Boston forum? 18:16:02 this is for mentors, trainers, coaches and anyone who's interested in this activity 18:16:38 we are flexible in terms of travel, we will ask the liaisons first especially if there's much interest in the area they cover 18:17:26 that makes sense 18:17:45 so someone can still be a liaison even if he/she is not able to travel to some of the trainings 18:17:50 i'm already mentor for other internship programs 18:17:54 i can help here as well 18:18:06 rodrigods ++ 18:18:07 mostly with material 18:18:09 we are also in discussion with a few OpenStack Days event organizers who would like to run a one day long version of the training 18:18:22 rodrigods: sounds great, thanks! 18:18:34 i'm based in boston, if the liason won't be able to attend for keystone i can fill in 18:18:49 so we will also ask help from the liaisons/teams to find local people for these smaller events 18:19:07 knikolla: great, thank you! 18:19:43 #link https://docs.openstack.org/upstream-training/ - this is the training website, we will start to update it soon: 18:20:13 #link ttps://etherpad.openstack.org/p/upstream-training-team - this is the list of volunteers and so far identified liaisons 18:20:29 #link https://etherpad.openstack.org/p/upstream-training-team 18:20:38 we will use [os-university] as ML tag 18:21:22 so if any of you would be interested in helping out just add yourself to the etherpad and look for the tag on the ML for news and also jump on the IRC channel I posted above 18:21:42 also feel free to ping me anytime if you have questions 18:21:51 ildikov awesome - thanks for all the information 18:22:03 I can give more updates, but I don't want to hijack the whole meeting now :) 18:22:38 lbragstad: thanks for the opportunity and support! 18:22:54 ildikov anytime, i'm happy to see the involvement here (thanks rodrigods knikolla) 18:23:00 ++ 18:23:11 thank you all! 18:23:17 ildikov thanks! 18:23:29 #topic VMT Update: keystonemiddleware diagram and docs 18:23:34 knikolla gagehugo 18:23:43 o/ 18:23:49 you both started working on this as a result of last weeks meeting - how are things going? 18:24:22 knikolla and I made a first draft for an architecture diagram for keystonemiddleware: http://i.imgur.com/1KIUsRh.png 18:24:26 what is a VMT? I thought that was the state I passed through to get to Canada? 18:24:29 #link http://i.imgur.com/1KIUsRh.png 18:24:45 ayoung vulnerability management team 18:24:49 Ah 18:25:06 we need to initiate a security analysis of all identity projects to get coverage 18:25:15 https://etherpad.openstack.org/p/pike-ptg-keystone-vmt-coverage 18:25:22 OK, makes sense now 18:25:47 gagehugo knikolla have either of you been able to get through to the security folks? 18:25:55 cc unrahul ^ 18:26:13 lbragstad: wanted to double check with keystone people first about the accuracy of the diagram 18:26:18 lbragstad: 18:26:48 gagehugo and just do double check - this is only targeting keystonemiddleware initially 18:26:53 yes 18:26:59 gagehugo: may be you can initiate the review by starting a gerrit review against security-analysis repo 18:27:02 do we have the ability to encrypt the memcache data? 18:27:15 unrahul sure 18:27:19 So that security community may also coment 18:27:21 thanks gagehugo 18:27:23 bknudson_, I swore we had that at some point 18:27:46 bknudson_ that would be something we should note then if that's the case 18:27:48 i know the ksm caching implementation is different than that of oslo.cache 18:29:17 http://git.openstack.org/cgit/openstack/keystonemiddleware/tree/keystonemiddleware/auth_token/_cache.py 18:29:41 http://git.openstack.org/cgit/openstack/keystonemiddleware/tree/keystonemiddleware/auth_token/_cache.py#n242 18:29:42 #link http://git.openstack.org/cgit/openstack/keystonemiddleware/tree/keystonemiddleware/auth_token/_cache.py#n243 18:29:46 lass SecureTokenCache(TokenCache): 18:30:08 also, a service can pass a cache handle to ksm 18:30:08 make that class SecureTokenCache(TokenCache): 18:30:10 (like swift) 18:30:11 ah ok 18:30:23 looks like the answer is yes 18:30:31 and ksm will use that cache handle/connection to do the lifting as well 18:31:16 ok, might be useful to put cache encryption into the diagram (the key is in the config file) 18:31:30 ++ 18:31:43 will do! 18:32:02 sounds like also need to open a review to the security repo 18:32:51 yup 18:33:03 one other thing about the diagram is that it might be easier to read if we numbered the steps 18:33:51 ah, yeah the process tutorial does that 18:34:17 basically provide a walkthrough then I assume 18:34:41 the diagram has arrows in it the denote some sort of flow 18:36:11 the arrows denote the initiator of the communication 18:36:30 looks like there are arrows here #link https://openstack-security.github.io/collaboration/2016/01/16/threat-analysis.html 18:37:01 and numbers also. cool, we'll update the diagram. 18:37:12 awesome - thanks again 18:37:17 we can keep reviewing offline 18:37:21 sure 18:37:23 ++ 18:37:32 gagehugo knikolla did either of you have anything else on VMT? 18:38:02 I think that is it for now? We can open a review and see what to do from there (after we update the diagram) 18:38:07 do you want me to keep the topic on the agenda for next week? 18:38:21 if it's a light agenda 18:38:24 lbragstad: sure 18:38:32 knikolla gagehugo sounds good 18:38:40 thanks guys, let's move on 18:38:47 #topic Pike specs 18:38:54 we have several specs in the works 18:39:07 figured we could use a little time during today's meeting to work through them 18:39:14 a couple of them are close 18:39:18 #topic Pike specs: API keys 18:39:26 rderose o/ 18:39:31 #link https://review.openstack.org/#/c/438761/ 18:39:31 We discussed this at the PTG, the problem: users storing their username/password in configuration files for their scripts / 3rd party tools. 18:39:40 Instead allow users to create access key credentials with limited scope (subset of their roles). 18:39:50 The key would be used like a password credential; thus, used to request a scoped token. 18:40:01 The questions we've been discussing is, should we instead, treat the keys more like bearer tokens where you could use the key to make an API call and not have to request a scoped token. 18:40:23 will it replace service users' username/password 18:40:24 ? 18:40:27 dstanek has an alternate spec proposed - https://review.openstack.org/#/c/440593/1 18:40:32 breton: yes 18:40:36 breton yes - that would be the intent 18:40:36 rderose: the key would be scoped then I assume? 18:40:44 oh well. 18:40:47 gagehugo: yes 18:40:54 i wonder how many people it is going to break 18:41:08 breton: shouldn't break anyone 18:41:16 username/password will still work 18:41:16 breton i assume we will gracefully switch 18:41:21 i don't expect it to break anyone 18:41:26 because it broke people when we moved to plugins 18:41:46 we should just encourage people to deploy service users more securely 18:41:54 not having to request a scoped token is follow-on work. 18:42:04 bknudson_: ++ 18:42:41 the big different between rderose's approach and dstanek's approach that I see is that one treats api keys like credentials and one treats it like a token 18:43:15 in one you use the api key to *get* a token and in the other you use the api key *as* the token 18:43:18 maybe we should continue the x509 stuff that gyee started some time ago 18:43:29 it has code ready on the server side 18:43:37 breton what's left to do there? 18:43:39 and the only thing that was missing is auth plugins 18:43:45 ah 18:44:07 i remember i could validate a token with it 18:44:19 breton does x509 allow you to delegate subsets of roles? 18:44:34 lbragstad: i don't remember, probably no. 18:44:58 but... we have trusts to delegate subset of roles 18:45:00 we'd have to find a way to get that in there in order for it to be on par with the direction of API keys 18:45:27 we could have a header for the roles to include in the token 18:45:48 (then we'd have to store the roles in the fernet token) 18:46:02 rderose the other difference between dstanek's approach and yours is that he requires the roles in the API key to be a subset 18:46:30 lbragstad: I see, but I'm not sure why that has to be a hard requirement 18:47:02 i think dstanek is out today :( 18:47:08 it would be nice to have him here for this discussion 18:47:16 and I like the approach of request a scope token for now (far less complicated) 18:47:25 and not request a scoped token as future work 18:47:37 the approach will solve the use case in the spec 18:48:47 yeah - i guess it depends on what we want this to look like eventually 18:49:09 we could implement it with using api key as an authentication method/auth plugin 18:49:12 honestly, i prefer the model where you don't exchange the API key for a token 18:49:23 notmorgan so a traditional api key 18:49:28 because that mirrors more accurately what an API-Key in other areas of the industry ends up being 18:49:44 it is a lot more work to make happen 18:49:52 true 18:49:52 changes to KSA, to KSM, and Keystone 18:49:56 vs just changes to Keystone 18:50:01 and an auth-plugin for KSA 18:50:24 you will likely still need to support API-Key for Token 18:50:46 notmorgan: I think we can get there, but yeah, to start API-key for token 18:50:48 if we use api access as an auth plugin, then i'd say we need to name it something different than API key (we can call it whatever we want) 18:51:03 i just don't want to accidentally advertise API keys when that's not what they are 18:51:07 i would really prefer to never implement api-key for tokne that is 18:51:16 notmorgan: ah 18:51:17 and yes do not name it "api-key" as the auth method 18:51:18 :) 18:51:34 currently, I've named it 'access-key' 18:51:46 can we call it something totally not related... 18:51:48 make up a word 18:51:57 unicorn-key 18:52:01 "foobaz-auth-key" 18:52:03 haha 18:52:24 not-a-key 18:52:32 knikolla: veto ;) 18:52:34 this-is-not-an-api-key-key 18:52:37 don-key 18:52:52 anyway 18:53:08 if we can avoid api-key-for-token it would be much better. however...... 18:53:20 discovery/catalog would still be needed. 18:53:38 could we pass the api key in the password? 18:53:46 bknudson_: in theory 18:53:54 but that is something i don't wnat 18:53:58 what’s the rush that means we can’t do the work for a real api key? 18:53:59 if we can avoid it 18:54:04 we tried to do something like that with TOTP 18:54:20 now... let me say this clearly 18:54:43 Since i am not going to implement this, my view is pretty much just a "what makes sense and mirrors the industry" 18:55:18 notmorgan so - take the long road and do real api keys? 18:55:25 I'm going to need to talk to keystone to get the service catalog. 18:55:34 API-Key should be used directly in lieu of the keystone-tokne, it should be a subset of roles, and should require an expiration on creation (where 0, or -1 is "never"). it should be revokable by the user. 18:55:40 notmorgan: I hear you, but... this would solve the use case and it doesn't prevent us from extending this in the future 18:56:07 rderose: if we don't ever want real api-keys. do it as an exchange for token 18:56:28 rderose: don't do a short-cut because "it solves the case but is easier" unless that is the mechanism you really want people to use 18:56:57 then it would be an application specific password - right? 18:56:58 remember, once it is implemented, it is in keystone *forever* effectively 18:57:04 lbragstad: pretty much 18:57:11 i'm fine with application-specific passwords 18:57:17 its a very different UX than api-keys 18:57:49 what are we aiming to solve? application-specific-passwords, API-Keys, a specific use-case that is agnostic to that, etc 18:58:24 another question - for the development cost, what's going to give users and operators more bang for their buck? 18:59:26 notmorgan: we're aiming to solve having users put there usernames/passwords in config files which has access to all of the user's roles 18:59:53 application-specific password would then use trusts *as well* for subsets of roles 18:59:53 notmorgan: there isn't really an industry standard around access/api keys 19:00:11 * breton whispers about time 19:00:12 do not lump in a new special password-thing that works totally different from current passwords, if it works like passwords 19:00:17 use "trusts" in that case. 19:00:22 breton thanks 19:00:30 and we're out of time, let's take this to -keystone 19:00:32 #endmeeting