18:00:01 <stevemar> #startmeeting keystone
18:00:02 <openstack> Meeting started Tue Nov  1 18:00:01 2016 UTC and is due to finish in 60 minutes.  The chair is stevemar. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:02 <crinkle> o/
18:00:03 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:05 <openstack> The meeting name has been set to 'keystone'
18:00:08 <stevemar> boom right at 2!
18:00:08 <lamt> o/
18:00:09 <knikolla> o/ just in time as i finished reading the proposed specs.
18:00:25 <bknudson> hi
18:00:32 <henrynash> (assembling)
18:00:34 <stevemar> hey its bknudson!
18:00:38 <gagehugo> o/
18:00:49 <jaugustine> o/
18:00:54 * stevemar goes up and gives bknudson a big hug
18:00:58 <stevemar> we've missed you
18:01:15 * bknudson hugs back
18:01:17 <notbreton> o/
18:01:19 <stevemar> we've got team at&t in the house too, lamt jaugustine and gagehugo
18:01:30 <gagehugo> :o
18:01:38 <stevemar> notbreton: ?! are you turning into morgan?
18:01:41 <samueldmq> hi all
18:02:05 <notbreton> stevemar: nah, I just have to irc via browser :(
18:02:07 * stevemar pokes lbragstad dstanek and dolphm with a stick
18:02:22 <stevemar> damn rackers
18:02:31 <stevemar> lets get going
18:02:37 <stevemar> #topic announcements
18:02:44 <stevemar> breton is core!
18:02:56 <gagehugo> Grats!
18:02:59 <notbreton> yey
18:03:01 <stevemar> thanks for all the reviews and high quality feedback!
18:03:01 <lamt> grats
18:03:04 <knikolla> congrats!
18:03:06 <bknudson> congratulations
18:03:20 <jaugustine> congrats !
18:03:24 <lbragstad> o/
18:03:28 <stevemar> \o
18:03:55 <stevemar> breton: notbreton let me know if i forgot to flip any switches
18:04:00 <henrynash> congratualtions!!!
18:04:04 <stevemar> thanks for agreeing to guard the gate :)
18:04:09 <ayoung> Excellent
18:04:12 <topol> o/
18:04:17 <topol> congrats!
18:04:22 <stevemar> :)
18:04:53 <stevemar> next announcement, i still don't have a draft of our turtle, which ayoung has nicked stoney
18:05:16 <stevemar> as soon as i get it, i'll forward it to the ML
18:05:28 <ayoung> #action ayoung Draw Stoney
18:05:39 <stevemar> #action ayoung Draw Stoney
18:05:51 <stevemar> #topic spec reviews!
18:05:56 <ayoung> everyone see the rought sketch>?
18:06:03 <stevemar> #link https://review.openstack.org/#/q/project:openstack/keystone-specs+status:open
18:06:33 <ayoung> #link https://twitter.com/admiyoung/status/789179752531668992
18:06:38 <stevemar> there are a few specs which were deemed a high priority as the summit, we should look at landing some of these
18:06:38 <ayoung> sorry
18:06:44 <stevemar> ayoung: s'all good
18:07:07 <stevemar> i've highlighted a few in the meeting etherpad
18:07:38 <stevemar> currently we only have 4 specs targeting ocata, one of which is already implemented (thanks rderose!)
18:08:11 <stevemar> i'm hoping for a few more to be approved (properties for projects, PCI x 2, MFA)
18:08:31 <notbreton> haven't I proposed fernet backends to O?
18:08:31 <stevemar> while we have a full room, is there a particular spec folks want to chat about?
18:08:55 <stevemar> notbreton: you did, i approved it (since it was already backlogged), see http://specs.openstack.org/openstack/keystone-specs/
18:09:01 <ayoung> Can we agree to not bikeshed on the specs, and instead accept imperfect ones that can be corrected as we learn more?
18:09:53 <stevemar> i agree that the spec will never reflect the final implementaiton and am willing to not bikeshed on certain topics. but some need to be a bit more baked than others
18:09:58 <samueldmq> breton: notbreton: congrats, well done
18:10:55 <ayoung> stevemar, legitimate concerns are legitimate
18:11:00 <samueldmq> stevemar: ++
18:11:02 <stevemar> would folks prefer to just review the specs? we can skip to the next topic
18:11:15 <stevemar> i figured now is a good time to ask the spec authors some quesitons in real time
18:11:38 <samueldmq> I just would like to avoid facing conceptual issues when implementing
18:11:56 <dstanek> stevemar: you have to poke harder next time
18:12:03 <stevemar> :)
18:12:06 <ayoung> properties for projects  is that a good idea?
18:12:11 <notbreton> do i need a spec to store token fernet keys in credential_api?
18:12:20 <lbragstad> samueldmq most of the time you can get around that by implementing as you write the spec
18:12:21 <notbreton> ayoung: yes
18:12:38 <stevemar> ayoung: we've had almost all operators come to us asking for it
18:12:48 <stevemar> "extras" doesn't work for them
18:12:49 <ayoung> stevemar, I know, but still not convinced.
18:12:51 <notbreton> everyone now does it via extras
18:12:52 <bknudson> should have known when we started adding security to identity it would be an unending request for more features.
18:12:52 <samueldmq> lbragstad: yes indeed, that helps
18:12:59 <notbreton> which is bad
18:13:03 <gagehugo> would be nice to get away from extras
18:13:21 <samueldmq> stevemar: what specs ? the ones in backlog ("Ocata approved specs") ?
18:13:22 <ayoung> this is like quotas.  It falls down on the details
18:13:26 <samueldmq> stevemar: the ones you want us to review
18:13:35 <stevemar> samueldmq: the ones highlighted in the meeting agenda
18:13:37 <ayoung> I've held off, but that one is making my -2 stamp itchy
18:13:52 <bknudson> if you have a good reason to -2 then please do it
18:13:56 <samueldmq> stevemar: thanks
18:14:07 <bknudson> otherwise we don't know what the reason is
18:14:11 <ayoung> I'm tempted to say that anything they are putting in Keystone should go into swift instead
18:14:30 <stevemar> ayoung: ? project properties?
18:14:35 <stevemar> in swift?
18:14:36 <ayoung> stevemar, yes
18:14:38 <ayoung> stevemar, yes
18:14:39 <stevemar> o_O
18:14:52 <ayoung> stevemar, swift is where you put unstructured data
18:15:01 <ayoung> we do a lot of that in Tripleo
18:15:10 <stevemar> link?
18:15:16 <ayoung> sure...
18:15:26 <ayoung> http://hardysteven.blogspot.com/2016/08/tripleo-deploy-artifacts-and-puppet.html
18:15:43 <ayoung> Also, Heat templates tend to have this kind of stuff....
18:16:08 <stevemar> you're also now telling folks they require swift ;)
18:16:12 <ayoung> Keystone, in general, should not have project specific data in it.
18:16:26 <ayoung> stevemar, no, I am telling them that there are alternatives to putting it in Keystone
18:16:41 <ayoung> and am challenging the notion that Keystone should be a RDBMS for the rest of OpenStack
18:17:13 <notbreton> it's not actually unstructured data. It's key-value, where both key and value are ascii. Used for aggregation, for example.
18:17:27 <ayoung> stevemar, for example, Post Orchestration Processing lead to the whole Vendor-Data spec for Nova
18:17:44 <ayoung> billing codes belongs with cloud kitty
18:18:00 <ayoung> Now, I agree we need better notifications, but that is true anyway
18:18:52 <stevemar> ayoung: i'm still not getting how i'm supposed to use swift for this? create an object for every project or something
18:18:52 <ayoung> notbreton, if we really don't think Keystone can even correctly store Quota data, how can we say it should store aggregates?
18:19:17 <ayoung> stevemar, yes
18:19:55 <ayoung> stevemar, if the data is really unstructured, use swift.  If it is specific to some subsystem, like billing, push off to billing
18:19:57 <ayoung> etc
18:20:15 <ayoung> I can't think of one example where Keystone is the best option.  Anyone care to come up with one?
18:20:47 <stevemar> it's metadata about a resource owned by keystone, if i delete the resource, the metadata will be cleaned up, not the case if i push it off
18:21:03 <ayoung> stevemar two bad things you said
18:21:12 <ayoung> one metadata is not meta.  It is just data
18:21:24 <stevemar> agreed, but alright
18:21:26 <ayoung> and 2 we already have notifications. it is up to the remote services to listen for them
18:21:35 <ayoung> and clean up.  They need to do so anyway
18:21:55 <ayoung> That is workflow, and there are already workflow engines galore
18:22:05 <ayoung> Heat, and Mistral and Ansible oh my
18:22:30 <ayoung> So, I'm tempted to push back on this one
18:22:47 <stevemar> ayoung: we also have 2 precedents now, nova stores metadata related to servers, and now you're suggesting swift for unstructured data
18:22:56 <notbreton> ayoung: I think keystone can correctly store quota limits data :p
18:23:21 <notbreton> ayoung: but lets talk about it later, after I post to ML.
18:23:37 <ayoung> notbreton, of course it can.  But yet, each time when we explain to the other projects what it means to do it, they balk.  Happend at just about every summit so far
18:23:37 <bknudson> we should create microservices so that there can be more experimentation
18:23:40 <stevemar> ayoung: who implemented the work for the tripleo artifacts stuff, shardy?
18:24:04 <ayoung> stevemar, possibly, or someone else on the team at his direction
18:24:20 <stevemar> i'll be happy to add him and someone from nova to the review
18:24:37 <stevemar> also, the issue of consistency across openstack projects comes up
18:25:00 <ayoung> stevemar, I'd like to see better laid out justifications.  I'm not holding it up, but I am also far from convinced
18:25:20 <ayoung> by "projects" here I assume you mean "services"
18:25:32 <stevemar> thats fine. gagehugo lamt jaugustine you guys proposed the spec and i've done all the talking :P
18:25:36 <stevemar> ayoung: correct
18:25:36 <ayoung> and, I don't think we are going to get that, and are, in fact likely to get conflicts
18:25:39 <gagehugo> ok
18:25:41 <notbreton> if many things from openstack need metadata, maybe there should be a service for it
18:25:47 <ayoung> what if both nova and neutron have a key names "network" for exdample
18:25:49 <stevemar> ayoung: nova and cinder do it the metadata way
18:25:56 <notbreton> projects needs metadata, servers need metadata, cinder stuff need metadata
18:26:03 <gagehugo> ^
18:26:27 <notbreton> can we have metadata-as-a-service?
18:26:35 <ayoung> I've voiced my concern.  We can move on.
18:26:37 <thingee> notbreton that has existed
18:26:43 <stevemar> notbreton: this is going back to your quota, we need a centralized service topic? :P
18:26:56 <stevemar> a wild thingee appears
18:27:03 <stevemar> thingee: what existed?
18:27:13 <ayoung> THink of "project" as a lable on others remote data instead of something that should be stored in Keystone
18:27:16 <notbreton> thingee: we need to talk about quote limits btw
18:27:20 <thingee> a central place for metadata
18:27:28 <stevemar> thingee: what was it called?
18:27:30 <ayoung> thingee, its called Swift
18:27:30 <thingee> I believe that was the graffiti project
18:27:35 <ayoung> :)
18:28:09 <bknudson> https://wiki.openstack.org/wiki/Graffiti
18:28:25 <stevemar> https://wiki.openstack.org/wiki/Graffiti
18:28:29 <stevemar> dammit bknudson
18:28:30 <thingee> https://wiki.openstack.org/wiki/Graffiti
18:28:31 <bknudson> it does seem like every project has metadata
18:28:31 <ayoung> So, a rule of thumb is, if when creating data for a remote machine, you have to define new datatypes, you are probably going to far.
18:28:35 <thingee> figured I should link it too :)
18:28:48 <bknudson> at least we're all looking at the same thing
18:28:50 <lbragstad> found the link - https://wiki.openstack.org/wiki/Graffiti
18:28:57 <lbragstad> ;)
18:29:18 <stevemar> ayoung please document your concerns in the review
18:29:23 <thingee> I'll email the dev ML with this link too, just in case.
18:29:29 <stevemar> :)
18:29:40 <ayoung> stevemar, wilco
18:29:47 <stevemar> we can continue to discuss it there
18:29:58 <stevemar> any other specs that folks want to talk about
18:30:00 <stevemar> ?
18:30:15 * ayoung on RBAC
18:30:24 <stevemar> i think the MFA and PCI notification specs are easily approved
18:30:29 <ayoung> ++
18:30:48 <gagehugo> what about the expired users one?
18:30:51 <ayoung> allow_expired is, as they say around here, wicked impohtant
18:30:53 <stevemar> "non-admin access to TOTP credentials" -- i need to see APIs there, it need to be baked a bit longer
18:31:06 <stevemar> gagehugo: so that one still confuses me a bit
18:31:23 <gagehugo> how so?
18:31:26 <stevemar> i don't like the fact that we've now got "disabled" and "expired" for users :(
18:31:45 <stevemar> #link https://review.openstack.org/#/c/383832/
18:32:06 <gagehugo> I don't either, but currently someone can be locked out and their enabled flag is still true
18:32:09 <ayoung> stevemar, would we treat them differently?
18:32:20 <ayoung> I think we would when validating a remote operation
18:32:29 <stevemar> ayoung: i suppose we should treat them differently.
18:32:42 <ayoung> like:  an expired user can't do a new operation, but if they created a trust, that trust should still be valid
18:32:42 <stevemar> if i'm expired and not disabled, then resetting my password should work
18:32:52 <stevemar> if i'm expired and disabled, resetting my password should not work
18:32:56 <ayoung> ++
18:32:59 <gagehugo> ++
18:33:10 <notbreton> lets just have it as boolean without any functionality
18:33:27 <stevemar> both should fail on other APIs
18:33:36 <stevemar> which i think we do
18:34:18 <stevemar> gagehugo: did you get the API from an existing source? or make that up?
18:34:32 <stevemar> the bit here: password_expires_at={operator}:{timestamp}
18:34:32 <notbreton> if it is needed for accounting and audit purposes, it can just be for information, and user's abilities should not depend on it
18:34:37 <gagehugo> that is made up
18:34:45 <gagehugo> well
18:34:54 <stevemar> gagehugo: would be nice to get the API working group to OK it then
18:35:09 <gagehugo> that bit came from another example that is linked in the comments
18:35:11 <stevemar> or if we have another service that already does something similar, we should do it like that
18:35:14 <stevemar> oh?
18:35:46 <stevemar> oh i see
18:35:47 <stevemar> http://specs.openstack.org/openstack/api-wg/guidelines/pagination_filter_sort.html#filtering
18:35:50 <gagehugo> yeah that
18:35:52 <stevemar> cool
18:36:06 <stevemar> gagehugo: add that to the spec so dummies like me don't waste meeting time :)
18:36:11 <stevemar> asking silly questions
18:36:12 <gagehugo> will do
18:36:30 <stevemar> i gotta go over this one again, but i think its OK
18:36:47 <gagehugo> oh I did have it, but lamt removed it :o
18:36:49 <stevemar> its the best we can do to fulfill the PCI requirement of seeing all the expired users
18:36:52 <gagehugo> I'll put it back
18:36:53 <lamt> :(
18:37:01 <stevemar> tsk tsk lamt
18:37:18 <stevemar> or creating a notification for them anyway
18:37:46 <notbreton> so does anybody even use notifications?
18:37:55 <ayoung> notbreton, ceilometer
18:38:11 <stevemar> ayoung: i think he means in production
18:38:17 <notbreton> yes
18:38:35 <stevemar> notbreton: i believe mfisch tried but ended up disabling them cause of rabbit
18:38:36 <ayoung> stevemar, notbreton as far as the devstack setup, that is the only service that is registered to read Keystone events
18:38:56 * notbreton sighs
18:38:57 <ayoung> You need to tune it.  We produce a lot of events
18:39:16 <ayoung> there are config options to remove notifications for token validations and rejections and such
18:40:02 <stevemar> you can use the non-CADF notifications, they are the default actually
18:40:06 <stevemar> and not get bombarded
18:40:13 <stevemar> with auth requests
18:40:18 <ayoung> Ask the operators who use it in production beyond that, but RDO and RH OSP enable them for ceilometer.
18:40:33 <lamt> it is to sate the security office's auditing demands in case they want it.  Probably will need to tune that.
18:40:51 * ayoung likes use of the word 'sate'
18:41:10 <ayoung> can I talk abouit RBAC now?
18:41:16 <stevemar> yeah
18:41:22 <stevemar> #topic Token Verify Role Check
18:41:45 <ayoung> OK...so I think I have a very good, keystonesque way to do what we tried to do with dynamic policy
18:41:58 <ayoung> I've written the spec quickly since the summit, so please ask questions
18:42:09 <ayoung> #link https://review.openstack.org/#/c/391624/
18:42:11 <stevemar> i haven't reviewed it yet :(
18:42:14 <ayoung> here is the TLDR
18:42:21 <stevemar> looks like lbragstad has
18:42:34 <ayoung> do the role check inside of Keystone during token validation
18:42:44 <ayoung> eseentially, split the Role check off the rest of policy
18:42:57 <bknudson> how does keystone what role a user needs?
18:42:57 <ayoung> the existing policy enforcement in the service specific code stays there
18:43:05 <ayoung> bknudson, based on the URL pattern
18:43:15 <ayoung> bknudson, the exampel I used was modify server
18:43:34 <ayoung> curl
18:43:34 <ayoung> -H "X-Auth-Token:    3d0b48b7bcdd"  \
18:43:34 <ayoung> -H "X-Subject-Token: adb5c708a55f"  \
18:43:34 <ayoung> -H "Content-type: application/json" \
18:43:34 <ayoung> -H "X-Request-URL: https://nova1:8774/v2.1/2497f6​/servers/​83cbdc \
18:43:34 <ayoung> GET \
18:43:36 <ayoung> https://keystone1:35357/v3/auth/tokens?service=identity&verb=PUT&nocatalog=True
18:43:47 <ayoung> the request URL gets passed to keystone
18:43:52 <ayoung> keystone then matches it agains:
18:44:06 <ayoung> ET /v2.1/​{tenant_id}​/servers/​{server_id}​
18:44:10 <ayoung> GET /v2.1/​{tenant_id}​/servers/​{server_id}​
18:44:31 <ayoung> as well as the service=identity  part
18:44:36 <ayoung> er...that is a type
18:44:37 <ayoung> shoudl be
18:44:45 <ayoung> service=compute
18:45:04 <ayoung> we use the implied roles mechanism to link from roles to the url Patterns
18:45:11 <bknudson> so there's a table of operation+URL to roles?
18:45:15 <ayoung> bknudson, yes
18:45:20 <ayoung> 2 tables
18:45:30 <lbragstad> so keystone will ultimately own a subset of the policy?
18:45:36 <ayoung> one for the url patterns, and then the existing role inference rules, but also allowing the patterns
18:46:00 <ayoung> lbragstad, the services will have their own rbac files, but they will get uploaded to Keystone at startup
18:46:19 <ayoung> the default rule will be role = Member
18:46:19 <lbragstad> so there will be some duplicate data between what keystone owns and the policies of each service
18:46:26 <ayoung> lbragstad, not a lot.
18:46:31 <lbragstad> but some
18:46:38 <lbragstad> do we have a way to keep them in sync?
18:46:44 <ayoung> lbragstad, the duplication will be more between the rbac rules and the matching of the URLs for the WSGI processing
18:47:01 <ayoung> for example, in Keystone, we could easily tag the roles required in the routers.py Mapping setup
18:47:03 <lbragstad> (ie. policy check in keystone passes but it fails the service policy check because the service policy has since been updated)
18:48:16 <ayoung> lbragstad, so, this is limiting it to only the role check.  If a service first said an API should be allwed by, say, Member, but decides that it shoudl really be Admin then, yes, you would need to update the Keystone rules
18:48:16 <lbragstad> keystone will be in charge of checking that the roles associated to a specific scope can do a specific action, yeah?
18:48:28 <ayoung> lbragstad, right
18:48:44 <stevemar> the only issue here is the same one for all the other changes for policy and authz. they need to be backward compatible, and it's going to be like moving a mountain (pushing changes across all the projects)
18:48:49 <ayoung> that check happens during the token validation call, after the exisitng logic in the token provider
18:48:57 <lbragstad> what's the benefit of keeping that check in the service if keystone is going to do it?
18:48:57 <ayoung> stevemar, so, it is backwards compat
18:49:04 <ayoung> that is why I am dancinfg with glee
18:49:21 <ayoung> lbragstad, the services provide the default file, not checked in the services
18:49:26 <ayoung> it is checked by middleware
18:49:43 <ayoung> we can make a first cut for them, but we can also keep them in a separate repo if we want
18:49:59 <ayoung> if we make the default Rule Member, and say Admin implies member, everything today still works
18:50:07 <lbragstad> ok - so if keystone is going to check the role policy in token validation - what other policy checks are needed?
18:50:08 <ayoung> also, this is not enabled by default
18:50:14 <ayoung> we give some transition time
18:50:25 <ayoung> lbragstad, the scope check still happens in code
18:50:32 <ayoung> or anything Neutron specific, for example
18:50:41 <ayoung> we don't do anything *but* the role check in Keystone
18:50:51 <lbragstad> scope as in - keystonemiddleware needs to check that a specific user can do a specific thing on a specific project?
18:50:57 <ayoung> maybe a few flags for keystone like things suych as is_admin_project
18:51:19 <ayoung> lbragstad, right:  check that the project in the token m atches the project for the resource (VM, network etc)
18:52:19 <ayoung> so...beat up the spec, ask quesitons. I might even put a FAQ section right into the spec
18:52:31 <ayoung> I think this is it.
18:52:47 <ayoung> It punts on some of the hard policy questions like the Moon project was trying to solve
18:53:01 <ayoung> we won't be responsibole for instance specific policy, for example
18:53:19 <ayoung> Oh, I also punted on endpoint specific, but we could support that in a future spec
18:53:33 <lbragstad> for that you'd need to do all the policy checks in keystone - i would think (which seemed like what moon was doing)
18:54:00 <ayoung> lbragstad, I have to admit, alot of this came from evaluating what Moon was doing.  I tried to strike a balance
18:54:05 <ayoung> Moon could not actually do what they wanted
18:54:17 <ayoung> by making their check in middleware, they lost the ability to query the database
18:54:24 <ayoung> they only had the URL and reuqest to work with
18:54:33 <ayoung> so no ownership check, for example
18:54:44 <stevemar> this is a massive change and definitely needs eyes on it
18:54:47 <ayoung> in order to do that, you need to do it after the resource is fetched from the database
18:54:56 <ayoung> stevemar, agreed, which is why I wanted to talk through it
18:55:12 <lbragstad> ayoung have you run this by any operators?
18:55:13 <ayoung> stevemar, it also solves the question of how we tell Horizon what role is needed
18:55:18 <ayoung> lbragstad, not yet
18:55:36 <ayoung> lbragstad, It hit me on THursday, and then a second wave of realization since you first read it
18:55:50 <stevemar> i need to actually read it
18:56:03 <ayoung> OK,  I surrender the conch for now
18:56:06 <stevemar> henrynash should weigh in on it too ^
18:56:13 <ayoung> stevemar, ++
18:56:26 <henrynash> I will (when I have read it too)!
18:56:31 <ayoung> stevemar, I meant to add in an example of how domain specific roles could be used here
18:56:51 <stevemar> the last item on the agenda is a quickie
18:57:01 <stevemar> #topic allow expired
18:57:02 <ayoung> IE; we won't allow project specific policy, but we might allow domain specific policy...
18:57:10 <stevemar> jamielennox is asking for reviews:
18:57:13 <stevemar> Keystone: https://review.openstack.org/#/c/382098/
18:57:13 <stevemar> keystoneclient: https://review.openstack.org/#/c/382099/
18:57:14 * dstanek needs to spend some time digesting this
18:57:45 <stevemar> oh also, if someone wants to reply to the mailing list: http://lists.openstack.org/pipermail/openstack/2016-October/017912.html go ahead and do so
18:58:28 <stevemar> i'm also out this [thursday -> sunday] just a heaads up
18:58:52 <ayoung> Evenbrite signup for PTG is up
18:58:58 <stevemar> oh nice
18:59:29 <ayoung> #link https://www.eventbrite.com/e/project-teams-gathering-tickets-27549298694
18:59:37 <ayoung> I think they are limiting to 500.
18:59:47 <lbragstad> total?!
18:59:49 <stevemar> thanks everyone!
18:59:55 <stevemar> lbragstad: yes, total
18:59:58 <gagehugo> wow
18:59:58 <stevemar> #endmeeting