| *** adriant has joined #openstack-keystone | 00:05 | |
| *** esp has quit IRC | 00:05 | |
| *** lamt has quit IRC | 00:06 | |
| *** esp has joined #openstack-keystone | 00:11 | |
| *** esp has left #openstack-keystone | 00:28 | |
| *** gyee has quit IRC | 00:29 | |
| *** zhurong has joined #openstack-keystone | 00:31 | |
| *** dave-mccowan has joined #openstack-keystone | 01:03 | |
| *** thorst has joined #openstack-keystone | 01:15 | |
| *** david-lyle has joined #openstack-keystone | 01:16 | |
| *** zhurong has quit IRC | 01:16 | |
| *** Shunli has joined #openstack-keystone | 01:23 | |
| *** zhurong has joined #openstack-keystone | 01:26 | |
| *** david-lyle has quit IRC | 01:34 | |
| *** gutter has joined #openstack-keystone | 01:49 | |
| *** ducttape_ has joined #openstack-keystone | 01:51 | |
| *** masber has quit IRC | 01:56 | |
| *** gutter has quit IRC | 01:57 | |
| *** namnh has joined #openstack-keystone | 01:59 | |
| *** dave-mccowan has quit IRC | 02:10 | |
| bigjools | ayoung: hey are you around? | 02:14 |
|---|---|---|
| ayoung | bigjools, I'm around...the planet from you! | 02:14 |
| bigjools | that's reassuring :) Hoping you have a minute to help with an auth issue | 02:14 |
| ayoung | I suppose it is too much to hope that you and I are going to finally catch that beer together next week, bigjools ? | 02:14 |
| bigjools | sadly no :( | 02:14 |
| bigjools | But I will be in Sydney | 02:15 |
| bigjools | So I am doing something like this, which is working ok: "openstack --os-auth-url=http://foo:35357/v3 --os-username=admin --os-password=keystone_admin_password --os-identity-api-version=3 --os-user-domain-id=default --os-project-name=admin domain list" | 02:16 |
| bigjools | but when I try that in the python API I'm getting a "Expecting to find domain in project" | 02:16 |
| ayoung | bigjools, you need an os project domain name | 02:17 |
| ayoung | for sample code I can show you... | 02:17 |
| bigjools | I am passing a project domain name | 02:17 |
| ayoung | bigjools, https://review.openstack.org/#/c/457818/1/examples/routes/routes_list.py using the session as per jamielennox in that example | 02:18 |
| ayoung | I sourced the devstack open conf file | 02:18 |
| bigjools | ok so I am loading via identity.v3.Password | 02:19 |
| ayoung | you need to explicitly set the auth plugin, but you get a different error if you miss that, I thihnk | 02:19 |
| bigjools | passing username/password/project_name/project_domain_name | 02:20 |
| ayoung | user domain name | 02:20 |
| *** dave-mccowan has joined #openstack-keystone | 02:20 | |
| ayoung | both user and project are namespaced to domains | 02:20 |
| bigjools | and I pass that, forgot to mention it | 02:21 |
| bigjools | the code is roughly: http://pastebin.ubuntu.com/24508919/ | 02:22 |
| bigjools | "domain_name" is the only parameter not set | 02:23 |
| *** shuyingya has joined #openstack-keystone | 02:26 | |
| ayoung | and you should not set that | 02:27 |
| ayoung | domain_name=login_domain_name, is wrong and is messing you uop | 02:27 |
| ayoung | bigjools, that should be project_domain_name | 02:28 |
| bigjools | yeah it's set to None | 02:28 |
| bigjools | I can reproduce minimally, let me paste | 02:28 |
| bigjools | ayoung: http://pastebin.ubuntu.com/24508935/ | 02:29 |
| bigjools | is OSC doing something else? it must be | 02:29 |
| ayoung | bigjools, still missing project_domain_name | 02:30 |
| ayoung | instead of | 02:30 |
| ayoung | auth = identity.v3.Password(auth_url='http://api.lab002000.proxprod1.dfj.io:35357/v3', username='admin', password='keystone_admin_password', project_name='admin', user_domain_name='Default') | 02:30 |
| ayoung | use] | 02:30 |
| ayoung | auth = identity.v3.Password(auth_url='http://api.lab002000.proxprod1.dfj.io:35357/v3', username='admin', password='keystone_admin_password', project_name='admin', user_domain_name='Default', project_domain_name='Default') | 02:30 |
| bigjools | ayoung: aha! thanks, that's fixed me | 02:31 |
| bigjools | I see the bug - the client code is dumb-as | 02:32 |
| *** zhurong has quit IRC | 02:34 | |
| bigjools | ayoung: will you be in Sydney later this year? | 02:35 |
| *** ducttape_ has quit IRC | 02:36 | |
| *** zhurong has joined #openstack-keystone | 02:37 | |
| ayoung | bigjools, nope. Sorry | 02:38 |
| bigjools | ayoung: damn! Too far for you? :) | 02:38 |
| ayoung | bigjools, that and I am not longer on OpenStack full time | 02:39 |
| ayoung | bigjools, I moved teams, working on kubevirt, which is technically under oVirt/RHEV-M | 02:40 |
| *** markvoelker has quit IRC | 02:40 | |
| bigjools | ah fair enough | 02:40 |
| bigjools | that explains your k8s tweets then | 02:40 |
| ayoung | We'll see how things shake out long term, but I've been doing Keystone exclusiviely for too long, starting to get Pigeon Holed. And it is a damn small hole. Witth lots of pigeon crap in it. | 02:40 |
| bigjools | There's a huge amount of work going on with k8s here too, but I'm not involved. | 02:41 |
| *** thorst has quit IRC | 02:41 | |
| bigjools | it's nice to stretch the wings for sure | 02:41 |
| ayoung | bigjools, I'd recommend getting involved. K8S is going to consume OpenStack | 02:42 |
| bigjools | it sounds that way, yeah | 02:43 |
| bigjools | containers are going to solve a ton of problems. We'll get new ones to replace those :) | 02:43 |
| *** esp has joined #openstack-keystone | 02:43 | |
| ayoung | bigjools, like, how do you launch a VM? | 02:44 |
| ayoung | heh | 02:44 |
| bigjools | :'D | 02:44 |
| *** ducttape_ has joined #openstack-keystone | 02:45 | |
| *** dave-mccowan has quit IRC | 02:51 | |
| *** masber has joined #openstack-keystone | 02:52 | |
| *** david-lyle has joined #openstack-keystone | 02:53 | |
| openstackgerrit | Merged openstack/keystone master: Stop using oslotest.mockpatch https://review.openstack.org/462033 | 02:55 |
| *** lucasxu has joined #openstack-keystone | 02:58 | |
| *** nicolasbock has quit IRC | 02:58 | |
| *** lucasxu has quit IRC | 03:00 | |
| *** shuyingy_ has joined #openstack-keystone | 03:06 | |
| *** zsli_ has joined #openstack-keystone | 03:10 | |
| *** rha_ has joined #openstack-keystone | 03:11 | |
| *** shuyingya has quit IRC | 03:11 | |
| *** rodrigod` has quit IRC | 03:11 | |
| *** mdavidson has quit IRC | 03:11 | |
| *** rha has quit IRC | 03:11 | |
| *** rodrigods has joined #openstack-keystone | 03:11 | |
| *** Shunli has quit IRC | 03:12 | |
| *** mdavidson has joined #openstack-keystone | 03:18 | |
| *** esp has left #openstack-keystone | 03:20 | |
| *** masber has quit IRC | 03:24 | |
| *** gongysh has joined #openstack-keystone | 03:33 | |
| *** ducttape_ has quit IRC | 03:33 | |
| *** thorst has joined #openstack-keystone | 03:41 | |
| *** markvoelker has joined #openstack-keystone | 03:44 | |
| openstackgerrit | yangweiwei proposed openstack/keystone master: Update fail message to test_database_conflicts https://review.openstack.org/462352 | 03:44 |
| *** thorst has quit IRC | 03:45 | |
| *** masber has joined #openstack-keystone | 04:11 | |
| *** zhurong has quit IRC | 04:12 | |
| *** thorst has joined #openstack-keystone | 04:12 | |
| openstackgerrit | Merged openstack/keystone master: Test config option 'user_enabled_default' with string type value https://review.openstack.org/462001 | 04:25 |
| *** thorst has quit IRC | 04:30 | |
| *** zhurong has joined #openstack-keystone | 04:36 | |
| *** ayoung has quit IRC | 05:10 | |
| *** links has joined #openstack-keystone | 05:18 | |
| *** ayoung has joined #openstack-keystone | 05:25 | |
| *** shuyingy_ has quit IRC | 05:35 | |
| *** shuyingya has joined #openstack-keystone | 05:35 | |
| *** Dinesh_Bhor has quit IRC | 05:41 | |
| *** Dinesh_Bhor has joined #openstack-keystone | 05:41 | |
| *** Dinesh_Bhor has quit IRC | 05:43 | |
| *** richm has quit IRC | 05:45 | |
| *** Dinesh_Bhor has joined #openstack-keystone | 05:48 | |
| *** arturb has joined #openstack-keystone | 06:09 | |
| *** voelzmo has joined #openstack-keystone | 06:23 | |
| *** thorst has joined #openstack-keystone | 06:27 | |
| *** thorst has quit IRC | 06:32 | |
| *** pcaruana has joined #openstack-keystone | 06:45 | |
| *** rha_ is now known as rha | 06:51 | |
| *** rha has joined #openstack-keystone | 06:51 | |
| openstackgerrit | yangweiwei proposed openstack/keystone master: Handel auto created domain when creating duplicate idp in federation https://review.openstack.org/462408 | 07:01 |
| *** jamielennox is now known as jamielennox|away | 07:06 | |
| *** thorst has joined #openstack-keystone | 07:28 | |
| *** tesseract has joined #openstack-keystone | 07:29 | |
| openstackgerrit | zhengliuyang proposed openstack/keystone master: Add notes about revoke token https://review.openstack.org/462417 | 07:30 |
| *** thorst has quit IRC | 07:33 | |
| *** aojea has joined #openstack-keystone | 07:48 | |
| *** zzzeek has quit IRC | 08:00 | |
| *** zzzeek has joined #openstack-keystone | 08:00 | |
| *** zsli_ has quit IRC | 08:06 | |
| *** zsli_ has joined #openstack-keystone | 08:07 | |
| *** xuhaigang has joined #openstack-keystone | 08:11 | |
| *** jaosorior_away is now known as jaosorior | 08:14 | |
| *** thorst has joined #openstack-keystone | 08:29 | |
| *** ducttape_ has joined #openstack-keystone | 08:34 | |
| *** ducttape_ has quit IRC | 08:39 | |
| *** thorst has quit IRC | 08:49 | |
| *** adriant has quit IRC | 08:57 | |
| *** zsli_ has quit IRC | 09:01 | |
| *** Shunli has joined #openstack-keystone | 09:03 | |
| *** Shunli has quit IRC | 09:03 | |
| *** zhurong has quit IRC | 09:06 | |
| *** zhurong has joined #openstack-keystone | 09:15 | |
| *** Shunli has joined #openstack-keystone | 09:18 | |
| *** tovin07 has quit IRC | 09:18 | |
| *** markvoelker has quit IRC | 09:25 | |
| *** links has quit IRC | 09:45 | |
| *** namnh has quit IRC | 09:47 | |
| *** mvk has quit IRC | 10:03 | |
| *** zhurong has quit IRC | 10:07 | |
| *** nicolasbock has joined #openstack-keystone | 10:08 | |
| *** richm has joined #openstack-keystone | 10:14 | |
| *** guoshan has joined #openstack-keystone | 10:20 | |
| *** zhurong has joined #openstack-keystone | 10:24 | |
| *** markvoelker has joined #openstack-keystone | 10:26 | |
| *** guoshan has quit IRC | 10:26 | |
| *** gongysh has quit IRC | 10:30 | |
| *** mvk has joined #openstack-keystone | 10:30 | |
| *** markvoelker has quit IRC | 10:33 | |
| *** thorst has joined #openstack-keystone | 10:46 | |
| *** thorst has quit IRC | 10:51 | |
| *** raildo has joined #openstack-keystone | 10:53 | |
| *** dave-mccowan has joined #openstack-keystone | 11:08 | |
| *** nicolasbock has quit IRC | 11:12 | |
| *** edmondsw has quit IRC | 11:16 | |
| *** lamt has joined #openstack-keystone | 11:17 | |
| *** sunset_system has joined #openstack-keystone | 11:18 | |
| *** lamt has quit IRC | 11:21 | |
| *** sunset_system has left #openstack-keystone | 11:23 | |
| *** thorst has joined #openstack-keystone | 11:33 | |
| *** Shunli has quit IRC | 11:34 | |
| *** nicolasbock has joined #openstack-keystone | 11:34 | |
| *** catintheroof has joined #openstack-keystone | 11:47 | |
| *** catintheroof has quit IRC | 11:51 | |
| *** edmondsw has joined #openstack-keystone | 12:17 | |
| *** zhurong has quit IRC | 12:30 | |
| *** lamt has joined #openstack-keystone | 12:32 | |
| *** thorst is now known as thorst_afk | 12:59 | |
| *** guoshan has joined #openstack-keystone | 13:00 | |
| *** shuyingya has quit IRC | 13:03 | |
| *** shuyingya has joined #openstack-keystone | 13:03 | |
| *** shuyingya has quit IRC | 13:03 | |
| *** shuyingya has joined #openstack-keystone | 13:09 | |
| *** shuyingya has quit IRC | 13:17 | |
| *** jsavak has joined #openstack-keystone | 13:23 | |
| *** markvoelker has joined #openstack-keystone | 13:23 | |
| *** chlong has joined #openstack-keystone | 13:32 | |
| *** zhurong has joined #openstack-keystone | 13:41 | |
| *** zhurong_ has joined #openstack-keystone | 13:50 | |
| *** zhurong has quit IRC | 13:51 | |
| *** lucasxu has joined #openstack-keystone | 13:52 | |
| *** jamielennox|away is now known as jamielennox | 13:58 | |
| *** phalmos has joined #openstack-keystone | 14:01 | |
| *** chlong has quit IRC | 14:01 | |
| *** zhurong_ has quit IRC | 14:12 | |
| *** chlong has joined #openstack-keystone | 14:14 | |
| *** catintheroof has joined #openstack-keystone | 14:20 | |
| *** catinthe_ has joined #openstack-keystone | 14:23 | |
| *** catintheroof has quit IRC | 14:24 | |
| *** markvoelker has quit IRC | 14:31 | |
| *** guoshan has quit IRC | 14:33 | |
| *** ducttape_ has joined #openstack-keystone | 14:37 | |
| *** voelzmo has quit IRC | 14:42 | |
| *** ducttape_ has quit IRC | 14:42 | |
| *** aloga has quit IRC | 14:42 | |
| *** ducttape_ has joined #openstack-keystone | 14:43 | |
| *** lamt has quit IRC | 14:43 | |
| *** aloga has joined #openstack-keystone | 14:43 | |
| *** voelzmo_ has joined #openstack-keystone | 14:44 | |
| *** gongysh has joined #openstack-keystone | 14:44 | |
| *** gongysh has quit IRC | 14:49 | |
| *** markvoelker has joined #openstack-keystone | 14:53 | |
| lbragstad | ayoung around? | 15:00 |
| ayoung | lbragstad, PERPETUALLY! | 15:00 |
| lbragstad | ayoung i know global roles has been brought up in the past | 15:01 |
| ayoung | Sure. | 15:01 |
| lbragstad | ayoung what were the main issues with that approach, if any? | 15:01 |
| ayoung | Kubernetes even has them, just calls them something else | 15:01 |
| ayoung | lbragstad, Well, the key point is that the way roles were implemented, they were never global | 15:02 |
| lbragstad | sure | 15:02 |
| ayoung | if there was a global roles implementation, it predates the keystonelight rewrite | 15:02 |
| lbragstad | and it must have never been ported to the kslite implementation | 15:02 |
| ayoung | lbragstad, even before, actually. | 15:03 |
| lbragstad | ah | 15:03 |
| ayoung | if there were global roles, they were only the RAX internal | 15:03 |
| lbragstad | ok | 15:03 |
| ayoung | Version 1 or somethuing | 15:03 |
| ayoung | but never a public impl. And, what we ended up having is non-global roles used to implement global roles | 15:03 |
| lbragstad | which is where the big issues stem from today | 15:04 |
| ayoung | Now, as far as scale goes, that is a big part of what I'll talk about in my preso | 15:04 |
| ayoung | namely, NIST rbac assumes a single organization | 15:04 |
| ayoung | but in a hierarchy, you want a self-similar pattern in each subunit of the hierarchy | 15:05 |
| lbragstad | yeah - it doesn't really account for any sort of project equivalent | 15:05 |
| ayoung | for example, lets say you have a public school system. | 15:05 |
| ayoung | Adding a new elementary school should not require adding a bunch of new roles, you apply the existing roles to the new school. | 15:05 |
| lbragstad | sure | 15:06 |
| ayoung | but NIST the role would be principal_pc_31 vs principal_pc_290 | 15:06 |
| ayoung | er | 15:06 |
| ayoung | ps | 15:06 |
| ayoung | PC 31 said we caught a dirty one... | 15:06 |
| lbragstad | right | 15:06 |
| *** jerrygb has joined #openstack-keystone | 15:07 | |
| ayoung | lbragstad, the early approach also was that a user was owned by a project | 15:07 |
| breton | what is global roles? | 15:08 |
| ayoung | I introduced the _Member_ role as a way to account for that, but to only have one kind of relationship between users and projects. Back when we split the assignemnt backend off of identity | 15:08 |
| ayoung | breton, in effect, the only global role was Admin | 15:08 |
| lbragstad | breton technically they don't exist yet - but a role that has operations that don't need to be scoped to a project (target) to make sense | 15:08 |
| ayoung | breton, you coming next week? | 15:08 |
| breton | ayoung: nope | 15:08 |
| ayoung | lbragstad, so Kubernetes has "Roles" and "ClusterRoles" with ClusterROles being global | 15:09 |
| lbragstad | sure | 15:10 |
| lbragstad | i want to know if there is anything stopping us from doing something like ClusterRoles in keystone? | 15:10 |
| lbragstad | like - long term | 15:10 |
| lbragstad | i understand the importance of the is_admin_project stuff - but what i'm really thinking about it making sure it doesn't stop us from getting to a true global role implementation at some point | 15:11 |
| lbragstad | in other words, i want to fix the security vulnerability now, but i don't want it to come at the expense of keeping us from a different implementation if we choose to move to it later | 15:12 |
| lbragstad | because the more that i think about all this - all i can come up with from the ideal solution perspective is global roles | 15:13 |
| lbragstad | and now i'm trying to track down the people who've probably thought about this before so that I get all the bits | 15:14 |
| breton | what will global roles do that scoped roles cannot do today? | 15:16 |
| *** jsavak has quit IRC | 15:16 | |
| lbragstad | breton the way that i was thinking about it | 15:17 |
| *** jsavak has joined #openstack-keystone | 15:17 | |
| lbragstad | breton is today you have services and services can do operations | 15:17 |
| lbragstad | right? | 15:17 |
| lbragstad | breton but some of those operations don't really make sense within the concept for a project (or even domain) scope | 15:17 |
| lbragstad | breton for example; creating an endpoint isn't really something that should be associated to a project | 15:18 |
| samueldmq | morning | 15:18 |
| lbragstad | samueldmq o/ | 15:19 |
| samueldmq | do we support mfa yet ? | 15:19 |
| samueldmq | lbragstad: o/ | 15:19 |
| lbragstad | samueldmq we do via TOTP | 15:19 |
| samueldmq | lbragstad: and what about https://specs.openstack.org/openstack/keystone-specs/specs/keystone/ocata/per-user-auth-plugin-requirements.html ? | 15:20 |
| lbragstad | breton but there are other things that make perfect sense for scoped roles - like creating an instance (because an instance should live within aproject_ | 15:20 |
| samueldmq | lbragstad: which is in the ocata repo | 15:20 |
| breton | oh btw i wish horizon could support our TOTP | 15:20 |
| lbragstad | breton so my general idea of all this was so make it so that global roles could be associated to global operations (like creating an endpoint, live migration, etc..) | 15:21 |
| ayoung | lbragstad, so, I think we could do ClusterRoles, and it might make sense to shoot for feature parity with Kubernetes for interoperability | 15:21 |
| breton | lbragstad: so one of the steps towards it would be to include service catalog to all token responses | 15:21 |
| ayoung | lbragstad, migrations would be tough | 15:21 |
| lbragstad | yeah | 15:21 |
| breton | lbragstad: because now we do it only for scoped tokens | 15:21 |
| lbragstad | breton yeah | 15:21 |
| lbragstad | that's the next tricky part | 15:21 |
| breton | but first we need to deprecate %(project_id) stuff | 15:22 |
| ayoung | lbragstad, breton actually you know who proposed that | 15:22 |
| lbragstad | because so far with what i've been able to come up with edmondsw | 15:22 |
| ayoung | jamielennox, a few years ago | 15:22 |
| ayoung | would make a lot of sense | 15:22 |
| ayoung | you get an unscoped token, and it has a minimal service catalog associated with it | 15:22 |
| lbragstad | is that unscoped is different project scoped which is different from domain scope which is different from global scope | 15:23 |
| lbragstad | i don't really think we should try to associate global roles to unscoped tokens | 15:23 |
| breton | lets drop domain scope | 15:23 |
| lbragstad | i feel like that would lead to more security issues given the nature of how we use unscoped tokens today | 15:24 |
| breton | who uses this stuff? | 15:24 |
| lbragstad | only we do | 15:24 |
| breton | do we? | 15:24 |
| lbragstad | well - in that we allow the creation and validation of them | 15:24 |
| lbragstad | none of the other projects are using domain scope, yet | 15:24 |
| breton | it seems to me that domains are used only for multiple sources of identity | 15:25 |
| breton | and... that's basically it | 15:25 |
| lbragstad | yeah - that's true | 15:25 |
| lbragstad | i was thinking about it from a user perspective | 15:26 |
| breton | (and i never really understood why a project should be in domain) | 15:26 |
| lbragstad | if i have the observer role on a domain, and i get a domain scoped token, i should be able to list all instances within the projects of that domain | 15:26 |
| lbragstad | (which is going to be a long way from what is done today - but ideally i think that makes sense) | 15:26 |
| lbragstad | regardless - i was thinking if we decide to do something with global roles, we should make a new scoping mechanism for it instead of trying to piggy back it on unscoped or project scoped tokens | 15:28 |
| lbragstad | so - a user would have to explicitly ask for a global token that contains the global roles they have | 15:28 |
| lbragstad | ayoung ^ | 15:29 |
| breton | > given the nature of how we use unscoped tokens today | 15:30 |
| breton | how do we use them today? | 15:30 |
| *** jsavak has quit IRC | 15:30 | |
| ayoung | " so - a user would have to explicitly ask for a global token that contains the global roles they have" ? | 15:30 |
| ayoung | Yes please | 15:30 |
| lbragstad | breton unscoped tokens are really only used to get a list of projects you have access to | 15:30 |
| *** jsavak has joined #openstack-keystone | 15:30 | |
| lbragstad | ideally - i want that same pattern for global roles workflows | 15:31 |
| lbragstad | like - i should be able to ask keystone "hey, what roles do i have across the whole deployment" | 15:31 |
| lbragstad | keystone could respond with "you have the keystone-admin role and the observer role" | 15:31 |
| lbragstad | then i can get a token for the observer role scoped to global | 15:32 |
| ayoung | lbragstad, in general, I want people to explicitly ask for the roles they want to provide on a token to some remote service | 15:32 |
| ayoung | like getting the key to right car before going out for a drive | 15:32 |
| lbragstad | yeah - that's the delegation case | 15:32 |
| lbragstad | which is totally something we need to solve, but i'm more thinking ofthe admin-ness issues here | 15:33 |
| dstanek | lbragstad: we'll need someone to replace me as API liaison for keystone | 15:33 |
| lbragstad | and how that can be fixed in an ideal system | 15:33 |
| lbragstad | dstanek :( | 15:33 |
| lbragstad | anyone up for volunteering? | 15:34 |
| lbragstad | we also need a docs liaison | 15:34 |
| *** chlong has quit IRC | 15:36 | |
| *** ducttap__ has joined #openstack-keystone | 15:38 | |
| *** ducttape_ has quit IRC | 15:38 | |
| *** ArchiFleKs has joined #openstack-keystone | 15:44 | |
| *** voelzmo_ has quit IRC | 15:46 | |
| ArchiFleKs | Hi, i'm looking at the docs for https://docs.openstack.org/developer/python-keystoneclient/using-api-v3.html to move from an v3 client to a versionless and discover URL automaticly (from what I understand this is what it does ?) but i'm getting an error An auth plugin is required to ' 'determine the endpoint URL | 15:46 |
| *** voelzmo has joined #openstack-keystone | 15:46 | |
| *** gyee has joined #openstack-keystone | 15:50 | |
| lbragstad | ayoung do i seem to be on the same track you are? | 15:52 |
| ayoung | lbragstad, yep | 15:53 |
| *** raildo has quit IRC | 15:53 | |
| *** lucasxu has quit IRC | 15:53 | |
| lbragstad | ayoung ok - some one question i have about is_admin_project | 15:53 |
| lbragstad | s/some/so/ | 15:53 |
| *** jaosorior has quit IRC | 15:54 | |
| lbragstad | ayoung it's fair to say that is the mechanism for communicating global context | 15:54 |
| lbragstad | ayoung a.) do we expect is_admin_project to be around when we finally move to global roles b.) what does that migration look like? | 15:54 |
| ayoung | lbragstad, I would say that is_admin_project is a way of implementing global roles by resuing the exisitng mechanisms | 15:55 |
| *** lucasxu has joined #openstack-keystone | 15:56 | |
| ayoung | there was the thought that is_admin_project should still reflect the same set of roles as scoped assignments, but be applicable cross projects | 15:56 |
| *** lucasxu has quit IRC | 15:56 | |
| *** lucasxu has joined #openstack-keystone | 15:56 | |
| lbragstad | ayoung sure - that makes snse | 15:57 |
| lbragstad | sense* | 15:57 |
| lbragstad | ayoung it's a little late for this now - but what if is_admin_project was something like `global` and was a boolean? | 15:57 |
| lbragstad | and initially we set it depending on if the context is scoped to the is_admin_project | 15:57 |
| ayoung | lbragstad, I think is roughly equivalent to what we have now | 15:58 |
| lbragstad | and later we modify it to work properly with global roles once all ofthat is in plce | 15:58 |
| *** voelzmo has quit IRC | 15:59 | |
| lbragstad | i'm thinking about that because an is_admin_project attribute doens't really make sense in a global role context because eventually global roles make the admin project obsolete | 15:59 |
| ayoung | lbragstad, I forget the rational for landing on is_admin_project as the name. We did have these discussions | 15:59 |
| *** lucasxu has quit IRC | 15:59 | |
| lbragstad | ayoung yeah - i don't remember | 15:59 |
| ayoung | lbragstad, mostly me and jamielennox IIRC | 16:00 |
| lbragstad | ayoung i was visiting with him a bit last night, but i don't think we got that far | 16:00 |
| lbragstad | i'm thinking about the long term road map and if we do the is admin project stuff on the backend and we set a general attribute for the global context then projects don't have to make another switch later on | 16:01 |
| ayoung | lbragstad, I know that edmondsw was part of the discussion. He came up with the general mechanism at the midcycle...in San Jose? | 16:01 |
| lbragstad | otherwise i imagine it would be confusing to have a is_admin_project attribute on something that's isn't "project" scoped | 16:02 |
| *** lucasxu has joined #openstack-keystone | 16:02 | |
| ayoung | lbragstad, I was thinking in terms of scope matching: ( token.project_id == resource.project or token.is_admin_project) | 16:02 |
| ayoung | as an override for scoped operations | 16:03 |
| lbragstad | sure | 16:03 |
| lbragstad | that makes sense | 16:03 |
| edmondsw | ayoung trying to catch up... I think I first mentioned global role assignments at the Austin summit | 16:03 |
| lbragstad | it's the second half of that statement that's the global bit | 16:03 |
| lbragstad | i guess i'm thinking of something like (token.project_id == resource.project_id) for the operations the make sense to operate within the scope of a project (i.e. launching an instance) | 16:04 |
| lbragstad | operations that are considered global (i.e. live migrate or create endpoint) would do a check like `if token.global` | 16:05 |
| edmondsw | actually, I think I mentioned it in Tokyo, but that was my first community involvement and I didn't push... I pushed in Austin :) | 16:05 |
| lbragstad | and token.global can be True based on scoping to the admin project initially | 16:05 |
| ayoung | lbragstad, its tenant vs. project IMHO | 16:05 |
| *** prashkre has joined #openstack-keystone | 16:06 | |
| *** raildo has joined #openstack-keystone | 16:06 | |
| lbragstad | and eventually we can rewire it to be True based on the actual proper usage of global roles | 16:06 |
| ayoung | edmondsw, Tokyo sounds right. I remember thrown a T-Shirt at you in the airport | 16:06 |
| edmondsw | ayoung yup | 16:06 |
| ayoung | lbragstad, if you do that, make the change in oslo-context first. | 16:07 |
| ayoung | That is where the defaulting happens. If there is no "is_admin_project" field in the token, it is oslo-context that defaults it to true | 16:07 |
| *** prashkre_ has joined #openstack-keystone | 16:07 | |
| lbragstad | i'm trying to think of this from the projects that have to consume it | 16:08 |
| lbragstad | and ideally - it doesn't matter how token.is_admin_project or token.global is set because that's something that we have control over in keystone | 16:09 |
| edmondsw | breton don't confused global scope with unscoped... a global role would be used to get a scoped token with scope=global | 16:09 |
| edmondsw | breton think of unscoped as the empty set and global scoped as the everything set... polar opposites | 16:10 |
| *** prashkre has quit IRC | 16:11 | |
| *** mvk has quit IRC | 16:11 | |
| lbragstad | edmondsw which means it should require a different scope target/mechanism | 16:11 |
| edmondsw | lbragstad I wonder if neutron is doing something with domain-scoped now? based on comments I saw, I think in bug 968696 | 16:11 |
| openstack | bug 968696 in OpenStack Identity (keystone) ""admin"-ness not properly scoped" [High,In progress] https://launchpad.net/bugs/968696 - Assigned to Adam Young (ayoung) | 16:11 |
| lbragstad | edmondsw that's a good question and i'm hoping to get answers to those types of things at the summit | 16:12 |
| lbragstad | or forum rather | 16:12 |
| ayoung | lbragstad, well, except that the thing I found out is they don't consume the token response data directly. They consume the oslo-context representation of it. | 16:13 |
| edmondsw | there's definitely some interplay between this discussion and the future of hierarchical multitenancy support in the various projects | 16:13 |
| lbragstad | ayoung so that's better | 16:13 |
| ayoung | lbragstad, lets not muddy the waters with calling it global | 16:14 |
| lbragstad | ayoung because we can make the change in one place and it should carry over into the other services as they upgrade to a new version oslo.context | 16:14 |
| ayoung | I think we are well on the way to a solution, and changing the name now, even if the new name is better, will slow adoption | 16:14 |
| ayoung | tenant vs project | 16:14 |
| ayoung | lets go with is_admin_project and you can blame me | 16:15 |
| lbragstad | ayoung sure - a name change regardless will slow adoption - but it will eventually happen | 16:15 |
| *** lucasxu has quit IRC | 16:15 | |
| *** arunkant has joined #openstack-keystone | 16:15 | |
| *** arunkant_ has joined #openstack-keystone | 16:16 | |
| *** arunkant_ has quit IRC | 16:16 | |
| lbragstad | admin project naming implies two things in my opinion, the first is that admin is assumed, the second is project | 16:17 |
| ayoung | it was the term that pre-0existed | 16:17 |
| ayoung | the admin project was a thing once | 16:17 |
| ayoung | according to termie anyway | 16:17 |
| lbragstad | yeah - i'm thinking about it down the road though | 16:18 |
| ayoung | I kindof like the idea that the admin project owns the service catalog and such | 16:18 |
| ayoung | but, K8S interop | 16:18 |
| lbragstad | the case the would be the opposite of the name would be giving Bob the Observer role within the global context | 16:18 |
| ayoung | Bob the Observer can he Observer it? Bob the Observer! Yes He Can! | 16:19 |
| lbragstad | Bob has the Observer role so that he can see everything in the deployment, but is_admin_project = True in that case? | 16:19 |
| lbragstad | i have a feel that's going to be super difficult to explain to peopl e | 16:19 |
| lbragstad | especially users | 16:19 |
| lbragstad | it kind of makes sense with an admin role, but that's really about it | 16:19 |
| *** lcastell has joined #openstack-keystone | 16:20 | |
| edmondsw | I think we could easily add global to oslo.context, deprecate is_admin_project, and eventually get rid of that | 16:20 |
| edmondsw | very little has adopted is_admin_project yet, and it would still work for them during the deprecation cycle | 16:21 |
| lbragstad | edmondsw we would have to replace is_admin_project with something (in keystone) | 16:21 |
| ayoung | lbragstad, so, there is also the idea of getting a role on a domain should have the ability to perform that operation no all projects in the domain without rescoping...etc | 16:21 |
| ayoung | with HMT we require rescoping for the moment. | 16:21 |
| lbragstad | ayoung yes - that's a good point | 16:21 |
| ayoung | lbragstad, OK, I feel good | 16:22 |
| edmondsw | lbragstad same thing... deprecate | 16:22 |
| lbragstad | (i.e. i'm the domain admin, let me see all the instance owned within the projects of my domain) | 16:22 |
| ayoung | I think you are really driving in on the issue here, and its been a while. | 16:22 |
| lbragstad | instances* | 16:22 |
| lbragstad | edmondsw can we deprecate an attribute in the API? | 16:22 |
| lbragstad | ayoung so long as I can see a path forward to get to an ideal system | 16:23 |
| edmondsw | lbragstad, well... if we had microversions... ;P | 16:23 |
| lbragstad | the is_admin_project stuff works - but i can see where it can cause a lot of confusion | 16:23 |
| * edmondsw ducks | 16:23 | |
| ayoung | lbragstad, so, once place I think I can be less stubborn is in the definition of the admin project | 16:23 |
| ayoung | I had it as one and only one, and I can now see an argument that it should be a list of projects instead | 16:23 |
| lbragstad | mmmm | 16:24 |
| ayoung | if only to provide people a way to transition from admins being all over the place | 16:24 |
| ayoung | and it might help with some of the nastiness in cleaning up the Tempest suites | 16:24 |
| lbragstad | i'd like to work on getting global role assignments in place instead | 16:24 |
| lbragstad | like - once we have that, then the migration is to give your admins the admin role globally | 16:24 |
| lbragstad | then their role assignment on the is_admin_project is no longer effective | 16:25 |
| lbragstad | and can be removed | 16:25 |
| lbragstad | (then the admin project eventually becomes just another project) | 16:25 |
| edmondsw | +1 | 16:25 |
| lbragstad | which seems way easier to process conceptually from a deployer and end user perspective | 16:26 |
| ayoung | lbragstad, why? | 16:26 |
| edmondsw | i.e., is_admin_project is the current solution, let's not expand on that... implement improvements as part of the better global roles mechanism that will supplant it | 16:26 |
| ayoung | why change the process now? THe naming, while different, has its own justifications, and I'd really rather not sell yet another name change | 16:27 |
| ayoung | whereas, is_admin_project is underway | 16:27 |
| lbragstad | ayoung the thing that would trip me us as an operator would be "why do i have to give the observer role to a user on the `admin_project`? I want them to have observer globally and want them to have notthing to do with projects or admin" | 16:27 |
| edmondsw | ayoung how many projects have we got to use is_admin_project so far? | 16:27 |
| ayoung | edmondsw, none | 16:27 |
| ayoung | edmondsw, do you think that is why? | 16:27 |
| edmondsw | ayoung I definitely think it contributes to confusion | 16:28 |
| lbragstad | true | 16:28 |
| lbragstad | ayoung i totally understand the hesistation of another rename | 16:28 |
| ayoung | OK, lets float the idea next week | 16:28 |
| lbragstad | renames suck | 16:28 |
| edmondsw | and confusion is the enemy of getting things in. But there are certainly other factors as well | 16:28 |
| ayoung | If it will speed things up, I am all for it | 16:28 |
| lbragstad | but if we can give projects a thing and say token.is_global (we can bikeshed later) and it means this context, build on that | 16:28 |
| edmondsw | ayoung I assume you will be there, with it in Boston, right? | 16:29 |
| edmondsw | I will be there as well | 16:29 |
| lbragstad | then we can wire it up with is_admin_project initially - and move to global roles later | 16:29 |
| ayoung | edmondsw, yes | 16:29 |
| edmondsw | cool | 16:29 |
| lbragstad | without the projects or oslo.context having to change | 16:29 |
| lbragstad | ideally - it would be a compromise wth the operators | 16:29 |
| lbragstad | but end users will see token.is_global when they should | 16:30 |
| lbragstad | thus solving the infamous bug | 16:30 |
| *** sjain has joined #openstack-keystone | 16:30 | |
| lbragstad | the compromise with operators would be "yes, we know the admin project is an operational wart... we're working on it by implementing global roles and migration to using those instead, the token.is_global api shouldn't change" | 16:31 |
| edmondsw | +1 | 16:31 |
| lbragstad | so some release down the road they'd be able to assign their operators globals roles | 16:31 |
| lbragstad | and the result would be the same, not having an impact on projects or having to go to each project and push for a change | 16:32 |
| *** jsavak has quit IRC | 16:32 | |
| lbragstad | but - they'd also get the ability to assign other roles globally, not just admin | 16:32 |
| *** jsavak has joined #openstack-keystone | 16:32 | |
| lbragstad | and the context of the change there makes sense with the attributes presented in the token (i.e. Bob has Observer and it is token.is_global) | 16:33 |
| lbragstad | from a consuming project perspective, that seems intuitive | 16:33 |
| ayoung | lbragstad, so, some ideas on top of the keystone policy source code impl that came to me last night | 16:33 |
| ayoung | I want to change the structure so that it has two parts: | 16:33 |
| ayoung | role check, scope check | 16:34 |
| ayoung | and I want to be able to globally turn off just the role check | 16:34 |
| edmondsw | turn off? | 16:34 |
| ayoung | even if we go with a policy file role check, I want to be able to configure it separately from the scope check | 16:34 |
| ayoung | edmondsw, so, either my proposal for middleware, or a deliberate policy.json file just for the role check | 16:34 |
| ayoung | but keep people from changing the scope check | 16:35 |
| edmondsw | I think the latter is essentially what I've been saying | 16:35 |
| edmondsw | do scope checks in code | 16:35 |
| ayoung | edmondsw, yeah, it grew from that discussion | 16:35 |
| edmondsw | and I don't mean defaults in code, like with policy... I mean totally in code, not changeable | 16:35 |
| ayoung | so, first step is to add a scope check to the policies | 16:35 |
| edmondsw | that doesn't preclude someone customizing policy to do *additional* scope checks along with role checks, but there would be a basis of hard-coded scope checks that will always be honored and aren't changeable | 16:36 |
| edmondsw | ayoung why is that the first step? | 16:36 |
| ayoung | edmondsw, right, so the enumeration we have now is good, we add a new field which is the scope check, and that does not get spewed into the policy file if autogenerated | 16:37 |
| ayoung | instead it always gets executed | 16:37 |
| edmondsw | ayoung I would say we need to go straight to doing the scope checks in code, NOT in policy | 16:37 |
| ayoung | edmondsw, I am agreeing with that | 16:37 |
| ayoung | edmondsw, let me link | 16:37 |
| lbragstad | fwiw - i think the scope check always needs to be explicit it we move it into code | 16:38 |
| ayoung | edmondsw, for example, the implied role API would have a field added here: http://git.openstack.org/cgit/openstack/keystone/tree/keystone/common/policies/implied_role.py#n18 | 16:38 |
| ayoung | modify the base object here... | 16:38 |
| ayoung | http://git.openstack.org/cgit/openstack/keystone/tree/keystone/common/policies/base.py#n35 | 16:39 |
| ayoung | so instead of it being an oslo-policy rule default, it is a KeystonePolicyRule | 16:39 |
| ayoung | extend from default, but over ride the enforce method to always check the scope value | 16:39 |
| *** pcaruana has quit IRC | 16:40 | |
| ayoung | edmondsw, we could do it right in the code calling points, but that might make it harder to audit | 16:42 |
| edmondsw | ayoung that might work, but I have a feeling it won't... thinking... | 16:43 |
| ayoung | I'm ok with either approach. More that I want the ability to shut off the policy enforcement doint the role check here than anything else. | 16:44 |
| edmondsw | ayoung I think it will get too complicated in some cases | 16:44 |
| edmondsw | and that we'll have to check in the API code itself | 16:44 |
| ayoung | And I do want to get the defaults for the scope check implemented | 16:44 |
| edmondsw | but I could be wrong | 16:44 |
| ayoung | edmondsw, the policy language for it is almosta ll in the cloudsample | 16:44 |
| ayoung | just needs to be untangled | 16:44 |
| edmondsw | ayoung note that some of the logic in cloudsample is wrong | 16:45 |
| edmondsw | but yeah | 16:45 |
| ayoung | http://git.openstack.org/cgit/openstack/keystone/tree/etc/policy.v3cloudsample.json#n37 needs to have the "Admin and " part removed for example | 16:45 |
| edmondsw | yeah, cloudsample should just go away when we do this | 16:45 |
| ayoung | right | 16:46 |
| edmondsw | because what it really added was more advanced scope checks :) | 16:46 |
| edmondsw | lbragstad you follow that? | 16:46 |
| ayoung | and knowledge of domains | 16:46 |
| lbragstad | getting there | 16:46 |
| edmondsw | knowledge of domains was for scope checks | 16:46 |
| ayoung | ++ | 16:47 |
| openstackgerrit | ayoung proposed openstack/keystone master: Add is_admin_project check to policy for non scoped operations https://review.openstack.org/257636 | 16:47 |
| openstackgerrit | ayoung proposed openstack/keystone master: Refactor is_admin https://review.openstack.org/387710 | 16:47 |
| openstackgerrit | ayoung proposed openstack/keystone master: Refactor Authorization: https://review.openstack.org/387161 | 16:47 |
| openstackgerrit | ayoung proposed openstack/keystone master: Prep for is_admin_project check for scoped operations https://review.openstack.org/462670 | 16:47 |
| ayoung | Damn...must have a rebase, only 2 of those should have gone in... | 16:47 |
| ayoung | one sec | 16:47 |
| lbragstad | so - i get the reason for splitting the scope checks from the policy file | 16:48 |
| lbragstad | because those should be in code | 16:48 |
| lbragstad | (i.e. the create instance API should enforce scope on a project) | 16:48 |
| *** erlon has joined #openstack-keystone | 16:48 | |
| lbragstad | (i.e. the create endpoint API should enforce scope globally) | 16:49 |
| lbragstad | is that what we're talking about here? | 16:49 |
| *** raildo has quit IRC | 16:49 | |
| *** lucasxu has joined #openstack-keystone | 16:49 | |
| edmondsw | lbragstad yes... and more specifically how to do it | 16:49 |
| lbragstad | ah | 16:50 |
| edmondsw | and that policy.cloudsample would go away when we do, since that was just about adding more scope advanced checking, which would now be in code | 16:50 |
| edmondsw | I thought you'd like that bit :) | 16:50 |
| lbragstad | yes | 16:50 |
| ayoung | OK...so here is a thought experiment. | 16:50 |
| ayoung | Say we had 2 policy checks already, one for RBAC, and one for scope | 16:50 |
| ayoung | and the RBAC one and the scope one could be separated. | 16:51 |
| lbragstad | you mean the definition in policy.json could be separated? | 16:51 |
| ayoung | in fact, now that the RBAC one no longer needs the object from the database, it can be performed as soon as the token has been validated | 16:51 |
| ayoung | as all it needs is the roles | 16:51 |
| ayoung | lbragstad, yes | 16:51 |
| edmondsw | ayoung that assumes we don't let someone impose additional scope checks on top of what we hardcode | 16:52 |
| lbragstad | yes | 16:52 |
| ayoung | rbac.json is now "identity:create_user" : "role:admin" | 16:52 |
| edmondsw | I would like to still have that flexibility | 16:52 |
| *** jsavak has quit IRC | 16:53 | |
| ayoung | edmondsw, even still, the RBAC check would not be where that is done | 16:53 |
| edmondsw | where then? | 16:53 |
| *** jsavak has joined #openstack-keystone | 16:53 | |
| ayoung | if you need custom policy, or what neutron does, that needs the object from the database, that is done where the scope check is done | 16:53 |
| lbragstad | that's just a scope check, right? | 16:53 |
| edmondsw | what is my hook into that, though? | 16:54 |
| ayoung | lbragstad, in my understanding, yes | 16:54 |
| lbragstad | scope checks involve service side process of resources | 16:54 |
| lbragstad | processing* | 16:54 |
| lbragstad | in order to determine "ownership | 16:54 |
| ayoung | edmondsw, I would say "leave the policy.json mechanism in place, just assume most are now no-ops" | 16:54 |
| *** prashkre_ has quit IRC | 16:55 | |
| ayoung | so custom scope checks are "in addition to" existing scope checks | 16:55 |
| ayoung | but the norm, and what most people should be thinking about when tuning, is the RBAC checks that match their organization | 16:55 |
| lbragstad | but how do you add additional custom scope checks if they are hardcoded in code? | 16:56 |
| ayoung | lbragstad, AND the code check with the check in the policy.json file | 16:56 |
| edmondsw | ayoung like this? http://paste.openstack.org/show/608893/ | 16:56 |
| edmondsw | lbragstad ^ | 16:56 |
| lbragstad | ideally - we're still allowing operators to modify which role is required for an operation, but the whole direction of this discussion has eluded to codifying scope checks | 16:57 |
| ayoung | edmondsw, yep | 16:57 |
| edmondsw | ++ | 16:57 |
| ayoung | edmondsw, ok, let me roll one step ahead | 16:57 |
| *** jsavak has quit IRC | 16:57 | |
| ayoung | lets say we want to do this in middleware instead of in each of the projects code bases | 16:57 |
| ayoung | why? | 16:58 |
| lbragstad | i'm not sure i understand the difference between steps one and three | 16:58 |
| edmondsw | lbragstad it allows for ayoung's middleware proposal | 16:58 |
| edmondsw | if we don't have the rbac middleware, then #1 is a noop | 16:58 |
| lbragstad | but don't we want the policy file to only contain role checks? | 16:58 |
| lbragstad | i thought we wanted the projects to hardcode their scope checks into the APIs | 16:59 |
| ayoung | lbragstad, so...let me rephrase it like this... | 16:59 |
| edmondsw | if you have/use the rbac middleware, then #3 is likely a no-op for most cases, but you could add stuff there if you wanted to | 16:59 |
| ayoung | edmondsw, right | 16:59 |
| edmondsw | I have to join a mtg now, guys... but good discussion | 16:59 |
| lbragstad | edmondsw thanks for helping out! | 17:00 |
| ayoung | lbragstad, when edmondsw wrote that above, he was jumping ahead. He could have written #1 as rbac.json policy check, but he knows where I am headed with this | 17:00 |
| ayoung | lbragstad, so that is what I meant in this slid: | 17:01 |
| ayoung | slide | 17:01 |
| ayoung | https://docs.google.com/presentation/d/1L31_x977Yrz9im3MapBxVUpcQSv7IGTJnCf7s6kbtFc/edit#slide=id.g110e9a5b29_1_20 | 17:01 |
| ayoung | I'm suggesting that we could then transition to this | 17:02 |
| ayoung | https://docs.google.com/presentation/d/1L31_x977Yrz9im3MapBxVUpcQSv7IGTJnCf7s6kbtFc/edit#slide=id.g1d63ac23f0_0_69 | 17:02 |
| *** jsavak has joined #openstack-keystone | 17:02 | |
| ayoung | apologies to anyone following the discussion. I'll make the slides public after next week | 17:02 |
| lbragstad | sure - i get that; the part i'm tripping over is why/how you'd want more custom scope checks | 17:03 |
| lbragstad | because I thought we determined we don't want people mucking with scope checks | 17:03 |
| lbragstad | the can muck with role checks, sure. but the scope checks are specific to the project/resource/service and have an opinion | 17:03 |
| ayoung | lbragstad, *I* don't. But since some people use it, we can't remove it without breaking them | 17:04 |
| ayoung | lbragstad, the IBMers do some custom thing. They are always vague about it. I just assumed it was an LDAP lookup | 17:04 |
| lbragstad | hmm ok | 17:04 |
| ayoung | Its probably some S390 dinosaur service accessed via COBOL and CICS | 17:05 |
| ayoung | APPC ans 3270 screen scraping | 17:05 |
| lbragstad | ok - so to be clear, this doesn't necessarily solve the admin-ness issues | 17:06 |
| lbragstad | right? | 17:07 |
| ayoung | lbragstad, right. | 17:07 |
| ayoung | lbragstad, adminness is a pre-req | 17:07 |
| lbragstad | that should be solved based on the earlier discussion of is_admin_project (possible refactoring) and getting services to consume it | 17:07 |
| lbragstad | and eventually global roles | 17:08 |
| ayoung | Kerect! | 17:08 |
| ayoung | I'll let you push on the rename | 17:08 |
| ayoung | lbragstad, meanwhile...could you please +2 the two pre-req patches for this, then? | 17:08 |
| lbragstad | ayoung yeah i can review them | 17:08 |
| ayoung | <openstackgerrit> ayoung proposed openstack/keystone master: Refactor is_admin https://review.openstack.org/387710 | 17:08 |
| ayoung | <openstackgerrit> ayoung proposed openstack/keystone master: Refactor Authorization: https://review.openstack.org/387161 | 17:08 |
| ayoung | they've been a round for a while, and it should be clear by the last patch why they are needed: | 17:09 |
| lbragstad | is this just refactoring all the auth/admin bits into a single place | 17:09 |
| ayoung | https://review.openstack.org/#/c/462670/1 is now a WIP patch | 17:09 |
| lbragstad | ? | 17:09 |
| ayoung | lbragstad, yeah and making it so we can call the same code that the decorators were using | 17:09 |
| lbragstad | ah right | 17:10 |
| lbragstad | that's coming back to me now | 17:10 |
| ayoung | it all comes down to the code change here: https://review.openstack.org/#/c/462670/1/keystone/identity/controllers.py | 17:10 |
| lbragstad | so we're moving away from @controller.protected | 17:10 |
| ayoung | without those other two patches, I can't call the logic inside the decorators directly | 17:10 |
| ayoung | precisely | 17:10 |
| *** aojea has quit IRC | 17:10 | |
| *** aojea has joined #openstack-keystone | 17:11 | |
| ayoung | and, I was attempting to put a clear delineation between our controller code and our authorization code, so the auth stuff could, in the distant future, be reusable | 17:11 |
| ayoung | that is why it all moved into authorization.py | 17:11 |
| lbragstad | where do you want to call that code from? | 17:11 |
| ayoung | nothing in there is "controller" specific except the decorator | 17:11 |
| ayoung | lbragstad, the authorization stuff ideally would move to oslo and be reusable cross projects | 17:12 |
| lbragstad | the decorators were convenient because there were really only used within keystone | 17:12 |
| ayoung | right. | 17:12 |
| ayoung | lbragstad, ah I remember | 17:12 |
| ayoung | we need a special fetch mechanism for Keystone to pull in the data that the other services get via a remote call, in order to use keystionemiddleware/auth_token | 17:13 |
| lbragstad | ok - so this sets us up to solve the delegation issues? | 17:13 |
| ayoung | but that is all aside. I really was just trying to get the authorization code all in one place, and be able to simplify calling it from multiple mehcanisms: directly, decorator, etc | 17:13 |
| lbragstad | (again - separate from the admin-ness issues) | 17:14 |
| ayoung | this sets us up to implement the is_admin_project check specificially | 17:14 |
| ayoung | delegation build on it after | 17:14 |
| *** aojea has quit IRC | 17:15 | |
| samueldmq | keystone officially has 2 new contributors coming from Outreachy | 17:15 |
| lbragstad | ok | 17:15 |
| samueldmq | results are out https://wiki.gnome.org/Outreachy/2017/MayAugust/#OpenStack | 17:15 |
| samueldmq | \o/ | 17:15 |
| samueldmq | sjain: congrats on getting accepted! | 17:16 |
| ayoung | Excellent! | 17:16 |
| sjain | Thank you so much :) | 17:16 |
| rodrigods | yay | 17:18 |
| rodrigods | congrats sjain | 17:18 |
| sjain | thanku @rodrigods, @ayoung looking forward to be part of this community | 17:19 |
| lbragstad | sjain welcome! | 17:19 |
| lbragstad | ayoung ok - i'm going to write this up but focus most of it on the admin-ness issues | 17:20 |
| ayoung | lbragstad, please do | 17:20 |
| sjain | thanku @lbragstad :) | 17:20 |
| ayoung | lbragstad, please focus on the fact that, even if we rename things to global,, the existing mechanism will solve the problem | 17:20 |
| lbragstad | ayoung sure - so long as we know going into it that global roles are what we're aiming for eventually | 17:21 |
| lbragstad | (i think?) | 17:21 |
| ayoung | lbragstad, your call. I'll support you on that. | 17:22 |
| lbragstad | ayoung i expect we'll get some more suggestions next week | 17:22 |
| ayoung | ++ | 17:22 |
| lbragstad | ayoung i'm not saying we have to go with global roles - but they just seem like the thing we want based on all the discussion we've had | 17:23 |
| ayoung | lbragstad, as I said, I'll support it. | 17:23 |
| ayoung | just want to make progress | 17:24 |
| lbragstad | agreed | 17:25 |
| lbragstad | i think this was good | 17:25 |
| lbragstad | ayoung thanks | 17:25 |
| *** tesseract has quit IRC | 17:30 | |
| *** raildo has joined #openstack-keystone | 17:32 | |
| *** basilAB has quit IRC | 17:45 | |
| *** gyee has quit IRC | 17:45 | |
| *** vaishali has quit IRC | 17:46 | |
| *** sjain has quit IRC | 17:47 | |
| *** prashkre_ has joined #openstack-keystone | 17:49 | |
| *** ducttap__ has quit IRC | 17:51 | |
| *** ducttape_ has joined #openstack-keystone | 17:52 | |
| *** ducttape_ has quit IRC | 17:56 | |
| *** rmascena has joined #openstack-keystone | 18:18 | |
| *** harlowja has quit IRC | 18:19 | |
| *** raildo has quit IRC | 18:21 | |
| *** jsavak has quit IRC | 18:28 | |
| *** jsavak has joined #openstack-keystone | 18:28 | |
| *** ducttape_ has joined #openstack-keystone | 18:29 | |
| *** vaishali has joined #openstack-keystone | 18:32 | |
| *** basilAB has joined #openstack-keystone | 18:33 | |
| *** Guest92102 is now known as redrobot | 18:42 | |
| *** jsavak has quit IRC | 18:49 | |
| *** jsavak has joined #openstack-keystone | 18:49 | |
| *** jsavak has quit IRC | 18:54 | |
| edmondsw | ayoung does the following work for you as a new commit message on https://review.openstack.org/#/c/387710/ ? "Consolidate duplicate policy checking code. Using the more complete logic from check_protection also allows assert_admin to work with more complicated admin_required rules." | 18:54 |
| edmondsw | I don't think you should ever actually need to put is_admin_project in admin_required, which I hope you'll agree after our earlier discussion today, so I really don't like that being the reasoning for this | 18:55 |
| *** ducttape_ has quit IRC | 18:57 | |
| *** jsavak has joined #openstack-keystone | 18:58 | |
| *** ducttap__ has joined #openstack-keystone | 18:58 | |
| *** ducttap__ has quit IRC | 19:13 | |
| *** ducttape_ has joined #openstack-keystone | 19:13 | |
| *** aojea has joined #openstack-keystone | 19:27 | |
| *** dave-mccowan has quit IRC | 19:30 | |
| openstackgerrit | Matthew Edmonds proposed openstack/keystone master: Prep for is_admin_project check for scoped operations https://review.openstack.org/462670 | 19:31 |
| *** prashkre_ has quit IRC | 19:33 | |
| openstackgerrit | Matthew Edmonds proposed openstack/keystone master: Refactor is_admin https://review.openstack.org/387710 | 19:35 |
| *** prashkre has joined #openstack-keystone | 19:36 | |
| *** dave-mccowan has joined #openstack-keystone | 19:43 | |
| *** dave-mcc_ has joined #openstack-keystone | 19:45 | |
| *** jsavak has quit IRC | 19:46 | |
| *** jsavak has joined #openstack-keystone | 19:47 | |
| *** jsavak has quit IRC | 19:47 | |
| *** jsavak has joined #openstack-keystone | 19:48 | |
| *** harlowja has joined #openstack-keystone | 19:48 | |
| *** dave-mccowan has quit IRC | 19:48 | |
| *** aojea has quit IRC | 19:50 | |
| *** aojea has joined #openstack-keystone | 19:50 | |
| *** aojea_ has joined #openstack-keystone | 19:52 | |
| *** jsavak has quit IRC | 19:52 | |
| *** aojea has quit IRC | 19:53 | |
| *** prashkre has quit IRC | 19:54 | |
| *** lbragstad_alt has joined #openstack-keystone | 20:02 | |
| *** jsavak has joined #openstack-keystone | 20:07 | |
| *** rmascena has quit IRC | 20:13 | |
| *** aojea_ has quit IRC | 20:19 | |
| *** jose-phillips has joined #openstack-keystone | 20:27 | |
| *** dave-mcc_ has quit IRC | 20:34 | |
| openstackgerrit | Lance Bragstad proposed openstack/keystone-specs master: Add policy roadmap for security https://review.openstack.org/462733 | 20:52 |
| *** jsavak has quit IRC | 20:54 | |
| *** thorst_afk has quit IRC | 20:59 | |
| *** lucasxu has quit IRC | 21:01 | |
| *** thorst_afk has joined #openstack-keystone | 21:03 | |
| *** thorst_afk has quit IRC | 21:08 | |
| *** jerrygb has quit IRC | 21:35 | |
| *** adriant has joined #openstack-keystone | 21:36 | |
| *** jsavak has joined #openstack-keystone | 21:43 | |
| *** lbragstad has quit IRC | 21:45 | |
| *** jsavak has quit IRC | 21:47 | |
| *** jsavak has joined #openstack-keystone | 21:49 | |
| *** mvk has joined #openstack-keystone | 21:51 | |
| *** edmondsw has quit IRC | 22:12 | |
| *** edmondsw has joined #openstack-keystone | 22:15 | |
| *** lamt has joined #openstack-keystone | 22:15 | |
| *** jsavak has quit IRC | 22:20 | |
| *** edmondsw has quit IRC | 22:20 | |
| openstackgerrit | Lance Bragstad proposed openstack/keystone-specs master: Add policy roadmap for security https://review.openstack.org/462733 | 22:21 |
| lbragstad_alt | ayoung: ^ | 22:21 |
| *** lamt has quit IRC | 22:27 | |
| *** jerrygb has joined #openstack-keystone | 22:37 | |
| *** jerrygb has quit IRC | 22:41 | |
| *** blake has joined #openstack-keystone | 22:48 | |
| *** catinthe_ has quit IRC | 23:08 | |
| *** erlon has quit IRC | 23:24 | |
| *** edmondsw has joined #openstack-keystone | 23:25 | |
| *** lamt has joined #openstack-keystone | 23:27 | |
| *** edmondsw has quit IRC | 23:30 | |
| *** lamt has quit IRC | 23:39 | |
| *** guoshan has joined #openstack-keystone | 23:40 | |
| *** ducttape_ has quit IRC | 23:44 | |
| *** lamt has joined #openstack-keystone | 23:46 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!