16:00:00 <lbragstad> #startmeeting keystone
16:00:01 <openstack> Meeting started Tue Nov 20 16:00:00 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:02 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:04 <openstack> The meeting name has been set to 'keystone'
16:00:11 <lbragstad> #link https://etherpad.openstack.org/p/keystone-weekly-meeting
16:00:13 <lbragstad> agenda ^
16:00:14 <kmalloc> i miss the pings. =/ i know....
16:00:22 <kmalloc> antispam...blah blah
16:00:33 <lbragstad> o/
16:01:30 <kmalloc> i added something to the agenda
16:01:32 <lbragstad> cool
16:01:35 <kmalloc> but... only if folks are around
16:01:37 <kmalloc> it can totally wait
16:01:39 <lbragstad> we'll give folks a few minutes to show up
16:01:45 <kmalloc> it's the keystone-as-an-idp continuation
16:01:55 <lbragstad> i expect attendance to be super light
16:01:57 <kmalloc> just getting specs spun up
16:01:58 <kmalloc> yueah
16:02:04 <kmalloc> i expect we just defer till next week
16:02:07 <kmalloc> yay holiday week
16:02:57 <gagehugo> o/
16:03:45 <gagehugo> turkey week
16:04:19 <lbragstad> alright - let's get started
16:04:24 <lbragstad> #topic announcements
16:04:26 <lbragstad> real quick
16:04:37 <lbragstad> #info stein-2 is just about 6 weeks away
16:04:42 <lbragstad> something to keep in mind
16:04:49 <lbragstad> especially from an implementation perspective
16:05:28 <lbragstad> also - i know several people missed the summit
16:05:43 <lbragstad> but i'll have a summary with links to relevant presentations coming soon
16:05:56 <gagehugo> lbragstad: cool
16:06:02 <lbragstad> my next week at the latest - i'm really just waiting for presentations to get published
16:06:08 <lbragstad> s/my/by/
16:06:48 <lbragstad> #topic keystone as an identity provider (proxy)
16:06:51 <lbragstad> kmalloc o/
16:07:04 <kmalloc> if it's just us
16:07:09 <kmalloc> we can defer
16:07:16 <kmalloc> but really i'll work on auth move spec
16:07:17 <lbragstad> ok - i'm fine with that
16:07:25 <gagehugo> ok
16:07:29 <kmalloc> and a spec to outline the principal object bit
16:07:30 <lbragstad> as a quick note
16:07:47 <lbragstad> i think we need to find way to draw out all the identity provider proxy stuff in documentation somehow
16:07:50 <kmalloc> auth move is straightforward and backlog
16:08:00 <kmalloc> yeah. that is what i think i wanted to cover here
16:08:04 <kmalloc> but it's 3 of us
16:08:14 <lbragstad> i noticed a few people in the session last week were expecting somethings higher level, and we don't really have anything like that yet
16:08:15 <kmalloc> and i don't think it's appropriate venue with this few folks
16:08:34 <kmalloc> I'll at least get a diagram up by next week sometime
16:08:42 <kmalloc> that shows the base architecture
16:08:47 <lbragstad> just wanted to put that on the radar in case folks have any clever ideas for mocking this up
16:08:49 <kmalloc> we can extract from there
16:09:09 <gagehugo> hmm
16:09:09 <kmalloc> an ingress/egress and full architecture diagram feels like the right 1st stab
16:09:11 <lbragstad> #info defer identity provider discussion to next week
16:09:14 <kmalloc> and extract APIs out from there
16:09:28 <kmalloc> because API mechanisms will be dictated by the intended architecture
16:09:31 <kmalloc> (and responses)
16:09:56 <kmalloc> i will avoid CRUD discussion bits
16:10:07 <kmalloc> just strictly auth flows and pure identity management
16:10:16 <kmalloc> what we need to cover
16:10:36 <lbragstad> ok
16:10:37 * kmalloc also wants to propose timestamp protocol support for token minting.
16:10:57 <lbragstad> that's another thing we need to go over as a larger group
16:11:03 <kmalloc> yes.
16:11:42 <gagehugo> ok
16:11:47 <kmalloc> i'll include UI bits in the architecture, but elide the bits about needing new API structure for it
16:11:59 <kmalloc> v3 would be a trainwreck to write a pure react/js ui over
16:12:01 <kmalloc> imo
16:12:10 <lbragstad> that's fine - just something that lays out the components and their relationships would help
16:12:13 <kmalloc> yeah
16:12:29 <kmalloc> i'll do that while on holiday and get as deep an architecture diagram built as possible
16:12:55 <lbragstad> cool
16:13:00 <lbragstad> #topic open discussion
16:13:26 <kmalloc> i'll def. include the design that /auth might reside 100% separate from the rest of keystone API in a deployment (locked behind HTTP mechanisms, since catalog points at crud and WWW-Authenticate is auth location)
16:14:14 <kmalloc> HAPPY WEEK OF TURKEY EATING IF YOU"RE IN THE US
16:14:18 * kmalloc kicks capslock
16:14:29 <gagehugo> lol
16:14:34 * lbragstad is looking forward to a couple days off
16:14:41 * gagehugo same
16:14:42 <kmalloc> lbragstad: you never get days off. you have kiddo
16:14:43 <kmalloc> :P
16:14:49 <gagehugo> heh
16:14:53 <kmalloc> i am looking forward to not feeling jetlagged
16:14:55 <kmalloc> its bad.
16:14:56 <lbragstad> time off is a figment of imagination
16:15:11 <kmalloc> i felt like i had the flu yesterday due to jetlag
16:15:39 <kmalloc> oh
16:15:45 <kmalloc> since we have 2 cores here
16:16:00 <kmalloc> lbragstad: https://review.openstack.org/#/c/618911/ (the RBAC Enforcer logging)
16:16:08 <kmalloc> that is 100% built into the RBACEnforcer
16:16:13 <kmalloc> its just way above policy.
16:16:30 <kmalloc> we might want to provide the format jdennis supplied, but the data is already logged debug
16:16:36 <kmalloc> as of Stein.
16:16:38 <lbragstad> ok
16:16:45 <kmalloc> i commented on the review and bug
16:16:53 <kmalloc> it's here: https://github.com/openstack/keystone/blob/5ff37f10280639737527226ca4bd97919d3725ea/keystone/common/rbac_enforcer/enforcer.py#L403-L426
16:16:54 <lbragstad> i thought it might be useful to build that directly into oslo.policy
16:16:59 <kmalloc> i agree
16:17:04 <kmalloc> it should go in oslo.policy if anywhere
16:17:05 <lbragstad> seems re-usable
16:17:06 <kmalloc> not in keystone
16:17:17 <kmalloc> now... warning
16:17:24 <kmalloc> there is sensitive data passed into the enforcer
16:17:32 <kmalloc> we can't mask the passwords if it's in oslo.policy, etc
16:17:43 <kmalloc> so... it reinforces DO NOT RUN IN DEBUG MODE
16:17:49 <lbragstad> true - but we only log in DEBUG, yeah?
16:17:53 <kmalloc> yes
16:17:59 <lbragstad> ok
16:18:04 <kmalloc> but MANY people keep reporting "oh this is emitted in debug"
16:18:09 <kmalloc> we even get it for KSA.
16:18:09 <jdennis> if we're going to log at least let's get the info right until such time it lands in oslo.policy
16:18:30 <kmalloc> jdennis: yeah it's already logged. it just isn't logged in the format you're proposing
16:18:39 <kmalloc> jdennis: i implemented that because it's useful for debugging.
16:18:39 <jdennis> no passwords are in the auth context
16:18:46 <kmalloc> jdennis: token data is
16:18:49 <kmalloc> the id, etc
16:18:51 <jdennis> kmalloc: nope, target data is not logged
16:18:52 <lbragstad> fwiw - i have another patch i need to get into oslo.policy and I'd like to propose a new release soon
16:18:56 <kmalloc> yes it is.
16:19:02 <jdennis> no it's not
16:19:09 <kmalloc> jdennis: https://github.com/openstack/keystone/blob/5ff37f10280639737527226ca4bd97919d3725ea/keystone/common/rbac_enforcer/enforcer.py#L424
16:19:12 <kmalloc> jdennis: it is.
16:19:32 <kmalloc> i know it is, i've used it for debug *a lot* when implementing flask migration
16:19:32 <jdennis> in what release is this in?
16:19:44 <kmalloc> as said, in stein forward
16:19:51 <kmalloc> partially in rocky
16:20:05 <kmalloc> but 100% in stein
16:20:37 <kmalloc> the only concern with oslo.policy doing it is that we can't mask sensitive data e.g. token ids
16:20:46 <kmalloc> but i'm ok with that as long as it's debug
16:21:24 <kmalloc> i think jdennis' format is better if it pushes down into oslo.policy
16:21:33 <kmalloc> vs. what i've implemented for keystone
16:22:31 <kmalloc> so, tl;dr I think that patch should be implemented in oslo.policy directly and I'd readily +2 it
16:23:00 <lbragstad> i'd like to propose a new oslo.policy release when https://review.openstack.org/#/c/614195/ merges anyway
16:23:13 <kmalloc> lbragstad: ++
16:23:46 <jdennis> what happens until this is fixed in oslo.policy? Why are we even logging anything?
16:24:23 <kmalloc> jdennis: you continue to get the logging keystone has.
16:24:46 <jdennis> kmalloc: but it's not usable :-)
16:25:08 <kmalloc> your definition of usable and mine are highly different.
16:25:27 <kmalloc> please propose changes at the RBACEnforcer layer for stein+
16:25:39 <kmalloc> if you want it there
16:26:18 <kmalloc> in rocky- i'd rather just add a logger to the decorator to include the target dict
16:26:36 <kmalloc> and could see that as an exception since there is no analogue in master anymore for backporting
16:27:02 <kmalloc> oslo.policy can include this for stien
16:27:13 <kmalloc> and it would impact 100% of projects by the nature of it existing
16:27:19 <kmalloc> rather than "just keystone"
16:27:33 * kmalloc is really trying to push this to where we get the biggest benefit
16:27:42 * kmalloc is core on oslo.policy as is lbragstad
16:27:57 <kmalloc> so i'm saying this as a "lets fix it where it belongs and get that released ASAP"
16:28:07 <kmalloc> not trying to defer it.
16:28:08 <kmalloc> really
16:28:25 <kmalloc> keystone-core owns oslo.policy
16:29:04 <jdennis> When looking at oslo.policy I found a number of comments saying oslo.policy can't log properly or there was some problem, why can't oslo.policy log properly?
16:29:11 <kmalloc> not sure
16:29:16 <kmalloc> but we should fix that
16:29:19 <lbragstad> jdennis do you have an example?
16:30:01 <jdennis> lbragstad: sorry, I didn't make a note of it, it was either in a commit message or a code comment, can't remember which
16:30:13 <lbragstad> ok - just curious
16:30:20 * kmalloc isn't seeing anything atm in code
16:30:24 <kmalloc> it might be a commit message
16:30:34 <kmalloc> but we do emit logs from oslo.policy
16:31:04 <jdennis> ok, anyway I get the drift, I'll move the logging to oslo.policy
16:31:04 <lbragstad> yeah - looks like we init a logger
16:31:09 <kmalloc> if there is an issue logging, lets get that fixed too ASAP :)
16:31:25 <lbragstad> jdennis feel free to ping me whenever you get that review up - happy to take a look
16:31:29 <kmalloc> jdennis: and want to be sure you don't think i'm deferring.
16:31:49 <kmalloc> i just want to get it where we make the biggest impact and solve the issue quickly :)
16:31:53 <jdennis> btw, I've had to do a number of fixes oslopolicy-checker to massage it into something more useful
16:31:57 <kmalloc> implementing it in each service is going to take for ever.
16:32:04 <kmalloc> jdennis: cool, i'll look for those fixes too
16:33:04 <lbragstad> anything else for today?
16:33:14 <kmalloc> i think thats it
16:33:22 <kmalloc> besides lbragstad owes us all coffee
16:33:31 <kmalloc> cause i can assert that fact :P
16:33:37 <kmalloc> ;)
16:33:46 <lbragstad> i could use a refill
16:34:06 <lbragstad> thanks for the time everyone, have a happy thanksgiving!
16:34:35 <lbragstad> #endmeeting