Thursday, 2017-05-04

*** adriant has joined #openstack-keystone00:05
*** esp has quit IRC00:05
*** lamt has quit IRC00:06
*** esp has joined #openstack-keystone00:11
*** esp has left #openstack-keystone00:28
*** gyee has quit IRC00:29
*** zhurong has joined #openstack-keystone00:31
*** dave-mccowan has joined #openstack-keystone01:03
*** thorst has joined #openstack-keystone01:15
*** david-lyle has joined #openstack-keystone01:16
*** zhurong has quit IRC01:16
*** Shunli has joined #openstack-keystone01:23
*** zhurong has joined #openstack-keystone01:26
*** david-lyle has quit IRC01:34
*** gutter has joined #openstack-keystone01:49
*** ducttape_ has joined #openstack-keystone01:51
*** masber has quit IRC01:56
*** gutter has quit IRC01:57
*** namnh has joined #openstack-keystone01:59
*** dave-mccowan has quit IRC02:10
bigjoolsayoung: hey are you around?02:14
ayoungbigjools, I'm around...the planet from you!02:14
bigjoolsthat's reassuring :) Hoping you have a minute to help with an auth issue02:14
ayoungI suppose it is too much to hope that you and I are going to finally catch that beer together next week, bigjools ?02:14
bigjoolssadly no :(02:14
bigjoolsBut I will be in Sydney02:15
bigjoolsSo 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
bigjoolsbut when I try that in the python API I'm getting a "Expecting to find domain in project"02:16
ayoungbigjools, you need an os project domain name02:17
ayoungfor sample code I can show you...02:17
bigjoolsI am passing a project domain name02:17
ayoungbigjools,   using the session as per jamielennox  in that example02:18
ayoungI sourced the devstack open conf file02:18
bigjoolsok so I am loading via identity.v3.Password02:19
ayoungyou need to explicitly set the auth plugin, but you get a different error if you miss that, I thihnk02:19
bigjoolspassing username/password/project_name/project_domain_name02:20
ayounguser domain name02:20
*** dave-mccowan has joined #openstack-keystone02:20
ayoungboth user and project are namespaced to domains02:20
bigjoolsand I pass that, forgot to mention it02:21
bigjoolsthe code is roughly:
bigjools"domain_name" is the only parameter not set02:23
*** shuyingya has joined #openstack-keystone02:26
ayoungand you should not set that02:27
ayoungdomain_name=login_domain_name,  is wrong and is messing you uop02:27
ayoungbigjools, that should be project_domain_name02:28
bigjoolsyeah it's set to None02:28
bigjoolsI can reproduce minimally, let me paste02:28
bigjoolsis OSC doing something else? it must be02:29
ayoungbigjools, still missing project_domain_name02:30
ayounginstead of02:30
ayoungauth = identity.v3.Password(auth_url='', username='admin', password='keystone_admin_password', project_name='admin', user_domain_name='Default')02:30
ayoungauth = identity.v3.Password(auth_url='', username='admin', password='keystone_admin_password', project_name='admin', user_domain_name='Default', project_domain_name='Default')02:30
bigjoolsayoung: aha! thanks, that's fixed me02:31
bigjoolsI see the bug - the client code is dumb-as02:32
*** zhurong has quit IRC02:34
bigjoolsayoung: will you be in Sydney later this year?02:35
*** ducttape_ has quit IRC02:36
*** zhurong has joined #openstack-keystone02:37
ayoungbigjools, nope.  Sorry02:38
bigjoolsayoung: damn! Too far for you? :)02:38
ayoungbigjools, that and I am not longer on OpenStack full time02:39
ayoungbigjools, I moved teams, working on kubevirt, which is technically under oVirt/RHEV-M02:40
*** markvoelker has quit IRC02:40
bigjoolsah fair enough02:40
bigjoolsthat explains your k8s tweets then02:40
ayoungWe'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
bigjoolsThere's a huge amount of work going on with k8s here too, but I'm not involved.02:41
*** thorst has quit IRC02:41
bigjoolsit's nice to stretch the wings for sure02:41
ayoungbigjools, I'd recommend getting involved.  K8S is going to consume OpenStack02:42
bigjoolsit sounds that way, yeah02:43
bigjoolscontainers are going to solve a ton of problems. We'll get new ones to replace those :)02:43
*** esp has joined #openstack-keystone02:43
ayoungbigjools, like, how do you launch a VM?02:44
*** ducttape_ has joined #openstack-keystone02:45
*** dave-mccowan has quit IRC02:51
*** masber has joined #openstack-keystone02:52
*** david-lyle has joined #openstack-keystone02:53
openstackgerritMerged openstack/keystone master: Stop using oslotest.mockpatch
*** lucasxu has joined #openstack-keystone02:58
*** nicolasbock has quit IRC02:58
*** lucasxu has quit IRC03:00
*** shuyingy_ has joined #openstack-keystone03:06
*** zsli_ has joined #openstack-keystone03:10
*** rha_ has joined #openstack-keystone03:11
*** shuyingya has quit IRC03:11
*** rodrigod` has quit IRC03:11
*** mdavidson has quit IRC03:11
*** rha has quit IRC03:11
*** rodrigods has joined #openstack-keystone03:11
*** Shunli has quit IRC03:12
*** mdavidson has joined #openstack-keystone03:18
*** esp has left #openstack-keystone03:20
*** masber has quit IRC03:24
*** gongysh has joined #openstack-keystone03:33
*** ducttape_ has quit IRC03:33
*** thorst has joined #openstack-keystone03:41
*** markvoelker has joined #openstack-keystone03:44
openstackgerrityangweiwei proposed openstack/keystone master: Update fail message to test_database_conflicts
*** thorst has quit IRC03:45
*** masber has joined #openstack-keystone04:11
*** zhurong has quit IRC04:12
*** thorst has joined #openstack-keystone04:12
openstackgerritMerged openstack/keystone master: Test config option 'user_enabled_default' with string type value
*** thorst has quit IRC04:30
*** zhurong has joined #openstack-keystone04:36
*** ayoung has quit IRC05:10
*** links has joined #openstack-keystone05:18
*** ayoung has joined #openstack-keystone05:25
*** shuyingy_ has quit IRC05:35
*** shuyingya has joined #openstack-keystone05:35
*** Dinesh_Bhor has quit IRC05:41
*** Dinesh_Bhor has joined #openstack-keystone05:41
*** Dinesh_Bhor has quit IRC05:43
*** richm has quit IRC05:45
*** Dinesh_Bhor has joined #openstack-keystone05:48
*** arturb has joined #openstack-keystone06:09
*** voelzmo has joined #openstack-keystone06:23
*** thorst has joined #openstack-keystone06:27
*** thorst has quit IRC06:32
*** pcaruana has joined #openstack-keystone06:45
*** rha_ is now known as rha06:51
*** rha has joined #openstack-keystone06:51
openstackgerrityangweiwei proposed openstack/keystone master: Handel auto created domain when creating duplicate idp in federation
*** jamielennox is now known as jamielennox|away07:06
*** thorst has joined #openstack-keystone07:28
*** tesseract has joined #openstack-keystone07:29
openstackgerritzhengliuyang proposed openstack/keystone master: Add notes about revoke token
*** thorst has quit IRC07:33
*** aojea has joined #openstack-keystone07:48
*** zzzeek has quit IRC08:00
*** zzzeek has joined #openstack-keystone08:00
*** zsli_ has quit IRC08:06
*** zsli_ has joined #openstack-keystone08:07
*** xuhaigang has joined #openstack-keystone08:11
*** jaosorior_away is now known as jaosorior08:14
*** thorst has joined #openstack-keystone08:29
*** ducttape_ has joined #openstack-keystone08:34
*** ducttape_ has quit IRC08:39
*** thorst has quit IRC08:49
*** adriant has quit IRC08:57
*** zsli_ has quit IRC09:01
*** Shunli has joined #openstack-keystone09:03
*** Shunli has quit IRC09:03
*** zhurong has quit IRC09:06
*** zhurong has joined #openstack-keystone09:15
*** Shunli has joined #openstack-keystone09:18
*** tovin07 has quit IRC09:18
*** markvoelker has quit IRC09:25
*** links has quit IRC09:45
*** namnh has quit IRC09:47
*** mvk has quit IRC10:03
*** zhurong has quit IRC10:07
*** nicolasbock has joined #openstack-keystone10:08
*** richm has joined #openstack-keystone10:14
*** guoshan has joined #openstack-keystone10:20
*** zhurong has joined #openstack-keystone10:24
*** markvoelker has joined #openstack-keystone10:26
*** guoshan has quit IRC10:26
*** gongysh has quit IRC10:30
*** mvk has joined #openstack-keystone10:30
*** markvoelker has quit IRC10:33
*** thorst has joined #openstack-keystone10:46
*** thorst has quit IRC10:51
*** raildo has joined #openstack-keystone10:53
*** dave-mccowan has joined #openstack-keystone11:08
*** nicolasbock has quit IRC11:12
*** edmondsw has quit IRC11:16
*** lamt has joined #openstack-keystone11:17
*** sunset_system has joined #openstack-keystone11:18
*** lamt has quit IRC11:21
*** sunset_system has left #openstack-keystone11:23
*** thorst has joined #openstack-keystone11:33
*** Shunli has quit IRC11:34
*** nicolasbock has joined #openstack-keystone11:34
*** catintheroof has joined #openstack-keystone11:47
*** catintheroof has quit IRC11:51
*** edmondsw has joined #openstack-keystone12:17
*** zhurong has quit IRC12:30
*** lamt has joined #openstack-keystone12:32
*** thorst is now known as thorst_afk12:59
*** guoshan has joined #openstack-keystone13:00
*** shuyingya has quit IRC13:03
*** shuyingya has joined #openstack-keystone13:03
*** shuyingya has quit IRC13:03
*** shuyingya has joined #openstack-keystone13:09
*** shuyingya has quit IRC13:17
*** jsavak has joined #openstack-keystone13:23
*** markvoelker has joined #openstack-keystone13:23
*** chlong has joined #openstack-keystone13:32
*** zhurong has joined #openstack-keystone13:41
*** zhurong_ has joined #openstack-keystone13:50
*** zhurong has quit IRC13:51
*** lucasxu has joined #openstack-keystone13:52
*** jamielennox|away is now known as jamielennox13:58
*** phalmos has joined #openstack-keystone14:01
*** chlong has quit IRC14:01
*** zhurong_ has quit IRC14:12
*** chlong has joined #openstack-keystone14:14
*** catintheroof has joined #openstack-keystone14:20
*** catinthe_ has joined #openstack-keystone14:23
*** catintheroof has quit IRC14:24
*** markvoelker has quit IRC14:31
*** guoshan has quit IRC14:33
*** ducttape_ has joined #openstack-keystone14:37
*** voelzmo has quit IRC14:42
*** ducttape_ has quit IRC14:42
*** aloga has quit IRC14:42
*** ducttape_ has joined #openstack-keystone14:43
*** lamt has quit IRC14:43
*** aloga has joined #openstack-keystone14:43
*** voelzmo_ has joined #openstack-keystone14:44
*** gongysh has joined #openstack-keystone14:44
*** gongysh has quit IRC14:49
*** markvoelker has joined #openstack-keystone14:53
lbragstadayoung around?15:00
ayounglbragstad, PERPETUALLY!15:00
lbragstadayoung i know global roles has been brought up in the past15:01
lbragstadayoung what were the main issues with that approach, if any?15:01
ayoungKubernetes even has them, just calls them something else15:01
ayounglbragstad, Well, the key point is that the way roles were implemented, they were never global15:02
ayoungif there was a global roles implementation, it predates the keystonelight rewrite15:02
lbragstadand it must have never been ported to the kslite implementation15:02
ayounglbragstad, even before, actually.15:03
ayoungif there were global roles, they were only the RAX internal15:03
ayoungVersion 1 or somethuing15:03
ayoungbut never a public impl.  And, what we ended up having is non-global roles used to implement global roles15:03
lbragstadwhich is where the big issues stem from today15:04
ayoungNow, as far as scale goes, that is a big part of what I'll talk about in my preso15:04
ayoungnamely, NIST rbac assumes a single organization15:04
ayoungbut in a hierarchy, you want a self-similar pattern in each subunit of the hierarchy15:05
lbragstadyeah - it doesn't really account for any sort of project equivalent15:05
ayoungfor example, lets say you have a public school system.15:05
ayoungAdding a new elementary school should not require adding a bunch of new roles, you apply the existing roles to the new school.15:05
ayoungbut NIST the role would be principal_pc_31  vs principal_pc_29015:06
ayoungPC 31 said we caught a dirty one...15:06
*** jerrygb has joined #openstack-keystone15:07
ayounglbragstad, the early approach also was that a user was owned by a project15:07
bretonwhat is global roles?15:08
ayoungI 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 identity15:08
ayoungbreton, in effect, the only global role was Admin15:08
lbragstadbreton 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 sense15:08
ayoungbreton, you coming next week?15:08
bretonayoung: nope15:08
ayounglbragstad, so Kubernetes has "Roles" and "ClusterRoles" with ClusterROles being global15:09
lbragstadi want to know if there is anything stopping us from doing something like ClusterRoles in keystone?15:10
lbragstadlike - long term15:10
lbragstadi 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 point15:11
lbragstadin 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 later15:12
lbragstadbecause the more that i think about all this - all i can come up with from the ideal solution perspective is global roles15:13
lbragstadand now i'm trying to track down the people who've probably thought about this before so that I get all the bits15:14
bretonwhat will global roles do that scoped roles cannot do today?15:16
*** jsavak has quit IRC15:16
lbragstadbreton the way that i was thinking about it15:17
*** jsavak has joined #openstack-keystone15:17
lbragstadbreton is today you have services and services can do operations15:17
lbragstadbreton but some of those operations don't really make sense within the concept for a project (or even domain) scope15:17
lbragstadbreton for example; creating an endpoint isn't really something that should be associated to a project15:18
lbragstadsamueldmq o/15:19
samueldmqdo we support mfa yet ?15:19
samueldmqlbragstad: o/15:19
lbragstadsamueldmq we do via TOTP15:19
samueldmqlbragstad: and what about ?15:20
lbragstadbreton 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
samueldmqlbragstad: which is in the ocata repo15:20
bretonoh btw i wish horizon could support our TOTP15:20
lbragstadbreton 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
ayounglbragstad, so, I think we could do ClusterRoles, and it might make sense to shoot for feature parity with Kubernetes for interoperability15:21
bretonlbragstad: so one of the steps towards it would be to include service catalog to all token responses15:21
ayounglbragstad, migrations would be tough15:21
bretonlbragstad: because now we do it only for scoped tokens15:21
lbragstadbreton yeah15:21
lbragstadthat's the next tricky part15:21
bretonbut first we need to deprecate %(project_id) stuff15:22
ayounglbragstad, breton actually you know who proposed that15:22
lbragstadbecause so far with what i've been able to come up with edmondsw15:22
ayoungjamielennox, a few years ago15:22
ayoungwould make a lot of sense15:22
ayoungyou get an unscoped token, and it has a minimal service catalog associated with it15:22
lbragstadis that unscoped is different project scoped which is different from domain scope which is different from global scope15:23
lbragstadi don't really think we should try to associate global roles to unscoped tokens15:23
bretonlets drop domain scope15:23
lbragstadi feel like that would lead to more security issues given the nature of how we use unscoped tokens today15:24
bretonwho uses this stuff?15:24
lbragstadonly we do15:24
bretondo we?15:24
lbragstadwell - in that we allow the creation and validation of them15:24
lbragstadnone of the other projects are using domain scope, yet15:24
bretonit seems to me that domains are used only for multiple sources of identity15:25
bretonand... that's basically it15:25
lbragstadyeah - that's true15:25
lbragstadi was thinking about it from a user perspective15:26
breton(and i never really understood why a project should be in domain)15:26
lbragstadif 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 domain15:26
lbragstad(which is going to be a long way from what is done today - but ideally i think that makes sense)15:26
lbragstadregardless - 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 tokens15:28
lbragstadso - a user would have to explicitly ask for a global token that contains the global roles they have15:28
lbragstadayoung ^15:29
breton> given the nature of how we use unscoped tokens today15:30
bretonhow do we use them today?15:30
*** jsavak has quit IRC15:30
ayoung" so - a user would have to explicitly ask for a global token that contains the global roles they have"  ?15:30
ayoungYes please15:30
lbragstadbreton unscoped tokens are really only used to get a list of projects you have access to15:30
*** jsavak has joined #openstack-keystone15:30
lbragstadideally - i want that same pattern for global roles workflows15:31
lbragstadlike - i should be able to ask keystone "hey, what roles do i have across the whole deployment"15:31
lbragstadkeystone could respond with "you have the keystone-admin role and the observer role"15:31
lbragstadthen i can get a token for the observer role scoped to global15:32
ayounglbragstad, in general, I want people to explicitly ask for the roles they want to provide on a token to some remote service15:32
ayounglike getting the key to right car before going out for a drive15:32
lbragstadyeah - that's the delegation case15:32
lbragstadwhich is totally something we need to solve, but i'm more thinking ofthe admin-ness issues here15:33
dstaneklbragstad: we'll need someone to replace me as API liaison for keystone15:33
lbragstadand how that can be fixed in an ideal system15:33
lbragstaddstanek :(15:33
lbragstadanyone up for volunteering?15:34
lbragstadwe also need a docs liaison15:34
*** chlong has quit IRC15:36
*** ducttap__ has joined #openstack-keystone15:38
*** ducttape_ has quit IRC15:38
*** ArchiFleKs has joined #openstack-keystone15:44
*** voelzmo_ has quit IRC15:46
ArchiFleKsHi, i'm looking at the docs for 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 URL15:46
*** voelzmo has joined #openstack-keystone15:46
*** gyee has joined #openstack-keystone15:50
lbragstadayoung do i seem to be on the same track you are?15:52
ayounglbragstad, yep15:53
*** raildo has quit IRC15:53
*** lucasxu has quit IRC15:53
lbragstadayoung ok - some one question i have about is_admin_project15:53
*** jaosorior has quit IRC15:54
lbragstadayoung it's fair to say that is the mechanism for communicating global context15:54
lbragstadayoung 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
ayounglbragstad, I would say that  is_admin_project  is a way of implementing global roles by resuing the exisitng mechanisms15:55
*** lucasxu has joined #openstack-keystone15:56
ayoungthere was the thought that is_admin_project should still reflect the same set of roles as scoped assignments, but be applicable cross projects15:56
*** lucasxu has quit IRC15:56
*** lucasxu has joined #openstack-keystone15:56
lbragstadayoung sure - that makes snse15:57
lbragstadayoung it's a little late for this now - but what if is_admin_project was something like `global` and was a boolean?15:57
lbragstadand initially we set it depending on if the context is scoped to the is_admin_project15:57
ayounglbragstad, I think is roughly equivalent to what we have now15:58
lbragstadand later we modify it to work properly with global roles once all ofthat is in plce15:58
*** voelzmo has quit IRC15:59
lbragstadi'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 obsolete15:59
ayounglbragstad, I forget the rational for landing on is_admin_project as the name. We did have these discussions15:59
*** lucasxu has quit IRC15:59
lbragstadayoung yeah - i don't remember15:59
ayounglbragstad, mostly me and jamielennox IIRC16:00
lbragstadayoung i was visiting with him a bit last night, but i don't think we got that far16:00
lbragstadi'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 on16:01
ayounglbragstad, I know that edmondsw was part of the discussion.  He came up with the general mechanism at the San Jose?16:01
lbragstadotherwise i imagine it would be confusing to have a is_admin_project attribute on something that's isn't "project" scoped16:02
*** lucasxu has joined #openstack-keystone16:02
ayounglbragstad, I was thinking in terms of scope matching:  ( token.project_id == resource.project or token.is_admin_project)16:02
ayoungas an override for scoped operations16:03
lbragstadthat makes sense16:03
edmondswayoung trying to catch up... I think I first mentioned global role assignments at the Austin summit16:03
lbragstadit's the second half of that statement that's the global bit16:03
lbragstadi 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
lbragstadoperations that are considered global (i.e. live migrate or create endpoint) would do a check like `if`16:05
edmondswactually, 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
lbragstadand can be True based on scoping to the admin project initially16:05
ayounglbragstad, its tenant vs. project IMHO16:05
*** prashkre has joined #openstack-keystone16:06
*** raildo has joined #openstack-keystone16:06
lbragstadand eventually we can rewire it to be True based on the actual proper usage of global roles16:06
ayoungedmondsw, Tokyo sounds right.  I remember thrown a T-Shirt at you in the airport16:06
edmondswayoung yup16:06
ayounglbragstad, if you do that, make the change in oslo-context first.16:07
ayoungThat is where the defaulting happens. If there is no "is_admin_project" field in the token, it is oslo-context that defaults it to true16:07
*** prashkre_ has joined #openstack-keystone16:07
lbragstadi'm trying to think of this from the projects that have to consume it16:08
lbragstadand ideally - it doesn't matter how token.is_admin_project or is set because that's something that we have control over in keystone16:09
edmondswbreton don't confused global scope with unscoped... a global role would be used to get a scoped token with scope=global16:09
edmondswbreton think of unscoped as the empty set and global scoped as the everything set... polar opposites16:10
*** prashkre has quit IRC16:11
*** mvk has quit IRC16:11
lbragstadedmondsw which means it should require a different scope target/mechanism16:11
edmondswlbragstad I wonder if neutron is doing something with domain-scoped now? based on comments I saw, I think in bug 96869616:11
openstackbug 968696 in OpenStack Identity (keystone) ""admin"-ness not properly scoped" [High,In progress] - Assigned to Adam Young (ayoung)16:11
lbragstadedmondsw that's a good question and i'm hoping to get answers to those types of things at the summit16:12
lbragstador forum rather16:12
ayounglbragstad, 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
edmondswthere's definitely some interplay between this discussion and the future of hierarchical multitenancy support in the various projects16:13
lbragstadayoung so that's better16:13
ayounglbragstad, lets not muddy the waters with calling it global16:14
lbragstadayoung 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.context16:14
ayoungI think we are well on the way to a solution, and changing the name now, even if the new name is better, will slow adoption16:14
ayoungtenant vs project16:14
ayounglets go with is_admin_project and you can blame me16:15
lbragstadayoung sure - a name change regardless will slow adoption - but it will eventually happen16:15
*** lucasxu has quit IRC16:15
*** arunkant has joined #openstack-keystone16:15
*** arunkant_ has joined #openstack-keystone16:16
*** arunkant_ has quit IRC16:16
lbragstadadmin project naming implies two things in my opinion, the first is that admin is assumed, the second is project16:17
ayoungit was the term that pre-0existed16:17
ayoungthe admin project was a thing once16:17
ayoungaccording to termie anyway16:17
lbragstadyeah - i'm thinking about it down the road though16:18
ayoungI kindof like the idea that the admin project owns the service catalog and such16:18
ayoungbut, K8S interop16:18
lbragstadthe case the would be the opposite of the name would be giving Bob the Observer role within the global context16:18
ayoung Bob the Observer  can he Observer it?   Bob the Observer!  Yes He Can!16:19
lbragstadBob has the Observer role so that he can see everything in the deployment, but is_admin_project = True in that case?16:19
lbragstadi have a feel that's going to be super difficult to explain to peopl e16:19
lbragstadespecially users16:19
lbragstadit kind of makes sense with an admin role, but that's really about it16:19
*** lcastell has joined #openstack-keystone16:20
edmondswI think we could easily add global to oslo.context, deprecate is_admin_project, and eventually get rid of that16:20
edmondswvery little has adopted is_admin_project yet, and it would still work for them during the deprecation cycle16:21
lbragstadedmondsw we would have to replace is_admin_project with something (in keystone)16:21
ayounglbragstad, 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...etc16:21
ayoungwith HMT we require rescoping for the moment.16:21
lbragstadayoung yes - that's a good point16:21
ayounglbragstad, OK,  I feel good16:22
edmondswlbragstad same thing... deprecate16:22
lbragstad(i.e. i'm the domain admin, let me see all the instance owned within the projects of my domain)16:22
ayoungI think you are really driving in on the issue here, and its been a while.16:22
lbragstadedmondsw can we deprecate an attribute in the API?16:22
lbragstadayoung so long as I can see a path forward to get to an ideal system16:23
edmondswlbragstad, well... if we had microversions... ;P16:23
lbragstadthe is_admin_project stuff works - but i can see where it can cause a lot of confusion16:23
* edmondsw ducks16:23
ayounglbragstad, so, once place I think I can be less stubborn is in the definition of the admin project16:23
ayoungI had it as one and only one, and I can now see an argument that it should be a list of projects instead16:23
ayoungif only to provide people a way to transition from admins being all over the place16:24
ayoungand it might help with some of the nastiness in cleaning up the Tempest suites16:24
lbragstadi'd like to work on getting global role assignments in place instead16:24
lbragstadlike - once we have that, then the migration is to give your admins the admin role globally16:24
lbragstadthen their role assignment on the is_admin_project is no longer effective16:25
lbragstadand can be removed16:25
lbragstad(then the admin project eventually becomes just another project)16:25
lbragstadwhich seems way easier to process conceptually from a deployer and end user perspective16:26
ayounglbragstad, why?16:26
edmondswi.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 it16:26
ayoungwhy change the process now?  THe naming, while different, has its own justifications, and I'd really rather not sell yet another name change16:27
ayoungwhereas, is_admin_project is underway16:27
lbragstadayoung 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
edmondswayoung how many projects have we got to use is_admin_project so far?16:27
ayoungedmondsw, none16:27
ayoungedmondsw, do you think that is why?16:27
edmondswayoung I definitely think it contributes to confusion16:28
lbragstadayoung i totally understand the hesistation of another rename16:28
ayoungOK, lets float the idea next week16:28
lbragstadrenames suck16:28
edmondswand confusion is the enemy of getting things in. But there are certainly other factors as well16:28
ayoungIf it will speed things up, I am all for it16:28
lbragstadbut if we can give projects a thing and say token.is_global (we can bikeshed later) and it means this context, build on that16:28
edmondswayoung I assume you will be there, with it in Boston, right?16:29
edmondswI will be there as well16:29
lbragstadthen we can wire it up with is_admin_project initially - and move to global roles later16:29
ayoungedmondsw, yes16:29
lbragstadwithout the projects or oslo.context having to change16:29
lbragstadideally - it would be a compromise wth the operators16:29
lbragstadbut end users will see token.is_global when they should16:30
lbragstadthus solving the infamous bug16:30
*** sjain has joined #openstack-keystone16:30
lbragstadthe 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
lbragstadso some release down the road they'd be able to assign their operators globals roles16:31
lbragstadand the result would be the same, not having an impact on projects or having to go to each project and push for a change16:32
*** jsavak has quit IRC16:32
lbragstadbut - they'd also get the ability to assign other roles globally, not just admin16:32
*** jsavak has joined #openstack-keystone16:32
lbragstadand 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
lbragstadfrom a consuming project perspective, that seems intuitive16:33
ayounglbragstad, so, some ideas on top of the keystone policy source code impl that came to me last night16:33
ayoungI want to change the structure so that it has two parts:16:33
ayoungrole check, scope check16:34
ayoungand I want to be able to globally turn off just the role check16:34
edmondswturn off?16:34
ayoungeven if we go with a policy file role check, I want to be able to configure it separately from the scope check16:34
ayoungedmondsw, so, either my proposal for middleware, or a deliberate policy.json file just for the role check16:34
ayoungbut keep people from changing the scope check16:35
edmondswI think the latter is essentially what I've been saying16:35
edmondswdo scope checks in code16:35
ayoungedmondsw, yeah, it grew from that discussion16:35
edmondswand I don't mean defaults in code, like with policy... I mean totally in code, not changeable16:35
ayoungso, first step is to add a scope check to the policies16:35
edmondswthat 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 changeable16:36
edmondswayoung why is that the first step?16:36
ayoungedmondsw, 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 autogenerated16:37
ayounginstead it always gets executed16:37
edmondswayoung I would say we need to go straight to doing the scope checks in code, NOT in policy16:37
ayoungedmondsw, I am agreeing with that16:37
ayoungedmondsw, let me link16:37
lbragstadfwiw - i think the scope check always needs to be explicit it we move it into code16:38
ayoungedmondsw, for example, the implied role API would have a field added here:
ayoungmodify the base object here...16:38
ayoungso instead of it being an oslo-policy rule default, it is a KeystonePolicyRule16:39
ayoungextend from default, but over ride the enforce method to always check the scope value16:39
*** pcaruana has quit IRC16:40
ayoungedmondsw, we could do it right in the code calling points, but that might make it harder to audit16:42
edmondswayoung that might work, but I have a feeling it won't... thinking...16:43
ayoungI'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
edmondswayoung I think it will get too complicated in some cases16:44
edmondswand that we'll have to check in the API code itself16:44
ayoungAnd I do want to get the defaults for the scope check implemented16:44
edmondswbut I could be wrong16:44
ayoungedmondsw, the policy language for it is almosta ll in the cloudsample16:44
ayoungjust needs to be untangled16:44
edmondswayoung note that some of the logic in cloudsample is wrong16:45
edmondswbut yeah16:45
ayoung    needs to have the "Admin and " part removed for example16:45
edmondswyeah, cloudsample should just go away when we do this16:45
edmondswbecause what it really added was more advanced scope checks :)16:46
edmondswlbragstad you follow that?16:46
ayoungand knowledge of domains16:46
lbragstadgetting there16:46
edmondswknowledge of domains was for scope checks16:46
openstackgerritayoung proposed openstack/keystone master: Add is_admin_project check to policy for non scoped operations
openstackgerritayoung proposed openstack/keystone master: Refactor is_admin
openstackgerritayoung proposed openstack/keystone master: Refactor Authorization:
openstackgerritayoung proposed openstack/keystone master: Prep for is_admin_project check for scoped operations
ayoungDamn...must have a rebase, only 2 of those should have gone in...16:47
ayoungone sec16:47
lbragstadso - i get the reason for splitting the scope checks from the policy file16:48
lbragstadbecause those should be in code16:48
lbragstad(i.e. the create instance API should enforce scope on a project)16:48
*** erlon has joined #openstack-keystone16:48
lbragstad(i.e. the create endpoint API should enforce scope globally)16:49
lbragstadis that what we're talking about here?16:49
*** raildo has quit IRC16:49
*** lucasxu has joined #openstack-keystone16:49
edmondswlbragstad yes... and more specifically how to do it16:49
edmondswand that policy.cloudsample would go away when we do, since that was just about adding more scope advanced checking, which would now be in code16:50
edmondswI thought you'd like that bit :)16:50
lbragstadyes16:50 here is a thought experiment.16:50
ayoungSay we had 2 policy checks already, one for RBAC, and one for scope16:50
ayoungand the RBAC one and the scope one could be separated.16:51
lbragstadyou mean the definition in policy.json could be separated?16:51
ayoungin 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 validated16:51
ayoungas all it needs is the roles16:51
ayounglbragstad, yes16:51
edmondswayoung that assumes we don't let someone impose additional scope checks on top of what we hardcode16:52
ayoungrbac.json is now "identity:create_user" : "role:admin"16:52
edmondswI would like to still have that flexibility16:52
*** jsavak has quit IRC16:53
ayoungedmondsw, even still, the RBAC check would not be where that is done16:53
edmondswwhere then?16:53
*** jsavak has joined #openstack-keystone16:53
ayoungif you need custom policy, or what neutron does, that needs the object from the database, that is done where the scope check is done16:53
lbragstadthat's just a scope check, right?16:53
edmondswwhat is my hook into that, though?16:54
ayounglbragstad, in my understanding, yes16:54
lbragstadscope checks involve service side process of resources16:54
lbragstadin order to determine "ownership16:54
ayoungedmondsw, I would say "leave the policy.json mechanism in place, just assume most are now no-ops"16:54
*** prashkre_ has quit IRC16:55
ayoungso custom scope checks are "in addition to" existing scope checks16:55
ayoungbut the norm, and what most people should be thinking about when tuning, is the RBAC checks that match their organization16:55
lbragstadbut how do you add additional custom scope checks if they are hardcoded in code?16:56
ayounglbragstad, AND the code check with the check in the policy.json file16:56
edmondswayoung like this?
edmondswlbragstad ^16:56
lbragstadideally - 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 checks16:57
ayoungedmondsw, yep16:57
ayoungedmondsw, ok, let me roll one step ahead16:57
*** jsavak has quit IRC16:57
ayounglets say we want to do this in middleware instead of in each of the projects code bases16:57
lbragstadi'm not sure i understand the difference between steps one and three16:58
edmondswlbragstad it allows for ayoung's middleware proposal16:58
edmondswif we don't have the rbac middleware, then #1 is a noop16:58
lbragstadbut don't we want the policy file to only contain role checks?16:58
lbragstadi thought we wanted the projects to hardcode their scope checks into the APIs16:59
ayounglbragstad, so...let me rephrase it like this...16:59
edmondswif 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 to16:59
ayoungedmondsw, right16:59
edmondswI have to join a mtg now, guys... but good discussion16:59
lbragstadedmondsw thanks for helping out!17:00
ayounglbragstad, 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 this17:00
ayounglbragstad, so that is what I meant in this slid:17:01
ayoungI'm suggesting that we could then transition to this17:02
*** jsavak has joined #openstack-keystone17:02
ayoungapologies to anyone following the discussion.  I'll make the slides public after next week17:02
lbragstadsure - i get that; the part i'm tripping over is why/how you'd want more custom scope checks17:03
lbragstadbecause I thought we determined we don't want people mucking with scope checks17:03
lbragstadthe can muck with role checks, sure. but the scope checks are specific to the project/resource/service and have an opinion17:03
ayounglbragstad, *I* don't.  But since some people use it, we can't remove it without breaking them17:04
ayounglbragstad, the IBMers do some custom thing.  They are always vague about it.  I just assumed it was an LDAP lookup17:04
lbragstadhmm ok17:04
ayoungIts probably some S390 dinosaur service accessed via COBOL and CICS17:05
ayoungAPPC ans 3270 screen scraping17:05
lbragstadok - so to be clear, this doesn't necessarily solve the admin-ness issues17:06
ayounglbragstad, right.17:07
ayounglbragstad, adminness is a pre-req17:07
lbragstadthat should be solved based on the earlier discussion of is_admin_project (possible refactoring) and getting services to consume it17:07
lbragstadand eventually global roles17:08
ayoungI'll let you push on the rename17:08
ayounglbragstad, meanwhile...could you please +2 the two pre-req patches for this, then?17:08
lbragstadayoung yeah i can review them17:08
ayoung<openstackgerrit> ayoung proposed openstack/keystone master: Refactor is_admin
ayoung<openstackgerrit> ayoung proposed openstack/keystone master: Refactor Authorization:
ayoungthey've been a round for a while, and it should be clear by the last patch why they are needed:17:09
lbragstadis this just refactoring all the auth/admin bits into a single place17:09
ayoung  is now a WIP patch17:09
ayounglbragstad, yeah and making it so we can call the same code that the decorators were using17:09
lbragstadah right17:10
lbragstadthat's coming back to me now17:10
ayoungit all comes down to the code change here:
lbragstadso we're moving away from @controller.protected17:10
ayoungwithout those other two patches, I can't call the logic inside the decorators directly17:10
*** aojea has quit IRC17:10
*** aojea has joined #openstack-keystone17:11
ayoungand, 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 reusable17:11
ayoungthat is why it all moved into authorization.py17:11
lbragstadwhere do you want to call that code from?17:11
ayoungnothing in there is "controller" specific except the decorator17:11
ayounglbragstad, the authorization stuff ideally would move to oslo and be reusable cross projects17:12
lbragstadthe decorators were convenient because there were really only used within keystone17:12
ayounglbragstad, ah I remember17:12
ayoungwe 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_token17:13
lbragstadok - so this sets us up to solve the delegation issues?17:13
ayoungbut 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, etc17:13
lbragstad(again - separate from the admin-ness issues)17:14
ayoungthis sets us up to implement the is_admin_project check specificially17:14
ayoungdelegation build on it after17:14
*** aojea has quit IRC17:15
samueldmqkeystone officially has 2 new contributors coming from Outreachy17:15
samueldmqresults are out
samueldmqsjain: congrats on getting accepted!17:16
sjainThank you so much :)17:16
rodrigodscongrats sjain17:18
sjainthanku @rodrigods, @ayoung looking forward to be part of this community17:19
lbragstadsjain welcome!17:19
lbragstadayoung ok - i'm going to write this up but focus most of it on the admin-ness issues17:20
ayounglbragstad, please do17:20
sjainthanku @lbragstad :)17:20
ayounglbragstad, please focus on the fact that, even if we rename things to global,, the existing mechanism will solve the problem17:20
lbragstadayoung sure - so long as we know going into it that global roles are what we're aiming for eventually17:21
lbragstad(i think?)17:21
ayounglbragstad, your call.  I'll support you on that.17:22
lbragstadayoung i expect we'll get some more suggestions next week17:22
lbragstadayoung 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 had17:23
ayounglbragstad, as I said, I'll support it.17:23
ayoungjust want to make progress17:24
lbragstadi think this was good17:25
lbragstadayoung thanks17:25
*** tesseract has quit IRC17:30
*** raildo has joined #openstack-keystone17:32
*** basilAB has quit IRC17:45
*** gyee has quit IRC17:45
*** vaishali has quit IRC17:46
*** sjain has quit IRC17:47
*** prashkre_ has joined #openstack-keystone17:49
*** ducttap__ has quit IRC17:51
*** ducttape_ has joined #openstack-keystone17:52
*** ducttape_ has quit IRC17:56
*** rmascena has joined #openstack-keystone18:18
*** harlowja has quit IRC18:19
*** raildo has quit IRC18:21
*** jsavak has quit IRC18:28
*** jsavak has joined #openstack-keystone18:28
*** ducttape_ has joined #openstack-keystone18:29
*** vaishali has joined #openstack-keystone18:32
*** basilAB has joined #openstack-keystone18:33
*** Guest92102 is now known as redrobot18:42
*** jsavak has quit IRC18:49
*** jsavak has joined #openstack-keystone18:49
*** jsavak has quit IRC18:54
edmondswayoung does the following work for you as a new commit message on ?  "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
edmondswI 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 this18:55
*** ducttape_ has quit IRC18:57
*** jsavak has joined #openstack-keystone18:58
*** ducttap__ has joined #openstack-keystone18:58
*** ducttap__ has quit IRC19:13
*** ducttape_ has joined #openstack-keystone19:13
*** aojea has joined #openstack-keystone19:27
*** dave-mccowan has quit IRC19:30
openstackgerritMatthew Edmonds proposed openstack/keystone master: Prep for is_admin_project check for scoped operations
*** prashkre_ has quit IRC19:33
openstackgerritMatthew Edmonds proposed openstack/keystone master: Refactor is_admin
*** prashkre has joined #openstack-keystone19:36
*** dave-mccowan has joined #openstack-keystone19:43
*** dave-mcc_ has joined #openstack-keystone19:45
*** jsavak has quit IRC19:46
*** jsavak has joined #openstack-keystone19:47
*** jsavak has quit IRC19:47
*** jsavak has joined #openstack-keystone19:48
*** harlowja has joined #openstack-keystone19:48
*** dave-mccowan has quit IRC19:48
*** aojea has quit IRC19:50
*** aojea has joined #openstack-keystone19:50
*** aojea_ has joined #openstack-keystone19:52
*** jsavak has quit IRC19:52
*** aojea has quit IRC19:53
*** prashkre has quit IRC19:54
*** lbragstad_alt has joined #openstack-keystone20:02
*** jsavak has joined #openstack-keystone20:07
*** rmascena has quit IRC20:13
*** aojea_ has quit IRC20:19
*** jose-phillips has joined #openstack-keystone20:27
*** dave-mcc_ has quit IRC20:34
openstackgerritLance Bragstad proposed openstack/keystone-specs master: Add policy roadmap for security
*** jsavak has quit IRC20:54
*** thorst_afk has quit IRC20:59
*** lucasxu has quit IRC21:01
*** thorst_afk has joined #openstack-keystone21:03
*** thorst_afk has quit IRC21:08
*** jerrygb has quit IRC21:35
*** adriant has joined #openstack-keystone21:36
*** jsavak has joined #openstack-keystone21:43
*** lbragstad has quit IRC21:45
*** jsavak has quit IRC21:47
*** jsavak has joined #openstack-keystone21:49
*** mvk has joined #openstack-keystone21:51
*** edmondsw has quit IRC22:12
*** edmondsw has joined #openstack-keystone22:15
*** lamt has joined #openstack-keystone22:15
*** jsavak has quit IRC22:20
*** edmondsw has quit IRC22:20
openstackgerritLance Bragstad proposed openstack/keystone-specs master: Add policy roadmap for security
lbragstad_altayoung: ^22:21
*** lamt has quit IRC22:27
*** jerrygb has joined #openstack-keystone22:37
*** jerrygb has quit IRC22:41
*** blake has joined #openstack-keystone22:48
*** catinthe_ has quit IRC23:08
*** erlon has quit IRC23:24
*** edmondsw has joined #openstack-keystone23:25
*** lamt has joined #openstack-keystone23:27
*** edmondsw has quit IRC23:30
*** lamt has quit IRC23:39
*** guoshan has joined #openstack-keystone23:40
*** ducttape_ has quit IRC23:44
*** lamt has joined #openstack-keystone23:46

Generated by 2.14.0 by Marius Gedminas - find it at!