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