| *** ayoung has quit IRC | 00:05 | |
| *** jamielennox|away is now known as jamielennox | 00:08 | |
| *** spzala has joined #openstack-keystone | 00:15 | |
| *** tobberydberg has joined #openstack-keystone | 00:19 | |
| *** adrian_otto has joined #openstack-keystone | 00:29 | |
| *** tobberydberg has quit IRC | 00:32 | |
| *** harlowja_ has quit IRC | 00:32 | |
| *** chrisplo has joined #openstack-keystone | 00:34 | |
| *** chrisplo_ has quit IRC | 00:36 | |
| *** adrian_otto has quit IRC | 00:37 | |
| *** spzala has quit IRC | 00:38 | |
| *** adrian_otto has joined #openstack-keystone | 00:41 | |
| *** diazjf has quit IRC | 00:41 | |
| *** harlowja has joined #openstack-keystone | 00:51 | |
| *** diazjf has joined #openstack-keystone | 00:52 | |
| *** hoangcx has joined #openstack-keystone | 00:57 | |
| *** tobberydberg has joined #openstack-keystone | 00:58 | |
| *** ayoung has joined #openstack-keystone | 00:58 | |
| *** ChanServ sets mode: +v ayoung | 00:58 | |
| *** tobberydberg has quit IRC | 01:04 | |
| *** jamielennox is now known as jamielennox|away | 01:04 | |
| *** spzala has joined #openstack-keystone | 01:07 | |
| openstackgerrit | Merged openstack/keystone: Expose idempotency issue with bootstrap https://review.openstack.org/408694 | 01:07 |
|---|---|---|
| *** chris_hultin|AWA is now known as chris_hultin | 01:12 | |
| *** adrian_otto has quit IRC | 01:15 | |
| *** chris_hultin is now known as chris_hultin|AWA | 01:18 | |
| *** jamielennox|away is now known as jamielennox | 01:20 | |
| *** guoshan has joined #openstack-keystone | 01:21 | |
| *** jrist has quit IRC | 01:21 | |
| *** liujiong has joined #openstack-keystone | 01:21 | |
| *** markvoelker has quit IRC | 01:22 | |
| *** markvoelker has joined #openstack-keystone | 01:27 | |
| *** tqtran has quit IRC | 01:33 | |
| *** jrist has joined #openstack-keystone | 01:34 | |
| *** Marcellin__ has quit IRC | 01:39 | |
| *** browne1 has quit IRC | 01:51 | |
| *** tobberydberg has joined #openstack-keystone | 02:01 | |
| *** diazjf has quit IRC | 02:14 | |
| *** tobberydberg has quit IRC | 02:14 | |
| *** zhangjl has joined #openstack-keystone | 02:28 | |
| openstackgerrit | gengchc2 proposed openstack/keystoneauth: Replace six.iteritems() with .items() https://review.openstack.org/408908 | 02:38 |
| *** tobberydberg has joined #openstack-keystone | 02:41 | |
| *** tobberyd_ has joined #openstack-keystone | 02:49 | |
| *** tobberydberg has quit IRC | 02:52 | |
| *** tobberyd_ has quit IRC | 02:54 | |
| *** harlowja has quit IRC | 02:55 | |
| *** tobberydberg has joined #openstack-keystone | 03:20 | |
| *** dave-mccowan has quit IRC | 03:25 | |
| *** links has joined #openstack-keystone | 03:29 | |
| openstackgerrit | Steve Martinelli proposed openstack/keystone-specs: clean up approved specs for ocata https://review.openstack.org/408931 | 03:29 |
| *** jrist has quit IRC | 03:30 | |
| stevemar | lbragstad: when you eventually see this, take a look at https://review.openstack.org/#/c/408931/ | 03:30 |
| *** rdo has quit IRC | 03:30 | |
| *** tobberydberg has quit IRC | 03:31 | |
| *** diazjf has joined #openstack-keystone | 03:31 | |
| *** jrist has joined #openstack-keystone | 03:33 | |
| *** rdo has joined #openstack-keystone | 03:33 | |
| *** diazjf has quit IRC | 03:39 | |
| *** guoshan has quit IRC | 03:55 | |
| *** tovin07 has quit IRC | 03:55 | |
| *** tovin07 has joined #openstack-keystone | 03:56 | |
| *** adriant has quit IRC | 03:56 | |
| *** tobberydberg has joined #openstack-keystone | 03:57 | |
| *** agrebennikov_ has joined #openstack-keystone | 03:58 | |
| *** tobberydberg has quit IRC | 04:02 | |
| *** udesale has joined #openstack-keystone | 04:06 | |
| *** nicolasbock has quit IRC | 04:08 | |
| *** spzala has quit IRC | 04:23 | |
| *** tovin07 has quit IRC | 04:31 | |
| *** tovin07 has joined #openstack-keystone | 04:32 | |
| openstackgerrit | Merged openstack/keystone: Make bootstrap idempotent when it needs to be https://review.openstack.org/408719 | 04:49 |
| *** links has quit IRC | 04:54 | |
| *** guoshan has joined #openstack-keystone | 04:56 | |
| *** tobberydberg has joined #openstack-keystone | 04:58 | |
| *** guoshan has quit IRC | 05:00 | |
| *** links has joined #openstack-keystone | 05:09 | |
| *** tobberydberg has quit IRC | 05:11 | |
| *** sc68cal has quit IRC | 05:12 | |
| *** madhaviy has joined #openstack-keystone | 05:12 | |
| *** sc68cal has joined #openstack-keystone | 05:24 | |
| *** tqtran has joined #openstack-keystone | 05:31 | |
| *** tqtran has quit IRC | 05:35 | |
| *** tobberydberg has joined #openstack-keystone | 05:38 | |
| *** tobberydberg has quit IRC | 05:43 | |
| *** GB21 has joined #openstack-keystone | 05:52 | |
| *** guoshan has joined #openstack-keystone | 06:09 | |
| *** guoshan has quit IRC | 06:13 | |
| *** guoshan has joined #openstack-keystone | 06:15 | |
| *** spzala has joined #openstack-keystone | 06:24 | |
| *** spzala has quit IRC | 06:29 | |
| openstackgerrit | Richard Avelar proposed openstack/keystone: Add doctor check for security_compliance https://review.openstack.org/408743 | 06:36 |
| *** tobberydberg has joined #openstack-keystone | 06:39 | |
| *** richm has quit IRC | 06:41 | |
| *** agrebennikov_ has quit IRC | 06:50 | |
| *** tobberydberg has quit IRC | 06:52 | |
| *** jaosorior has joined #openstack-keystone | 07:00 | |
| *** tesseract has joined #openstack-keystone | 07:07 | |
| *** tesseract is now known as Guest99997 | 07:07 | |
| *** GB21 has quit IRC | 07:09 | |
| *** Guest99997 is now known as tesseract- | 07:13 | |
| *** tobberydberg has joined #openstack-keystone | 07:19 | |
| *** GB21 has joined #openstack-keystone | 07:21 | |
| *** guoshan has quit IRC | 07:22 | |
| *** tobberydberg has quit IRC | 07:23 | |
| *** rcernin has joined #openstack-keystone | 07:28 | |
| *** guoshan has joined #openstack-keystone | 07:30 | |
| *** GB21 has quit IRC | 07:34 | |
| *** tqtran has joined #openstack-keystone | 07:34 | |
| *** tqtran has quit IRC | 07:39 | |
| *** GB21 has joined #openstack-keystone | 07:45 | |
| *** Dinesh_Bhor has quit IRC | 07:49 | |
| *** GB21 has quit IRC | 07:55 | |
| *** jaosorior has quit IRC | 07:55 | |
| *** jaosorior has joined #openstack-keystone | 07:55 | |
| *** jaosorior has quit IRC | 08:00 | |
| *** jaosorior has joined #openstack-keystone | 08:02 | |
| *** pnavarro has joined #openstack-keystone | 08:02 | |
| *** udesale has quit IRC | 08:07 | |
| *** pcaruana has joined #openstack-keystone | 08:16 | |
| openstackgerrit | Richard Avelar proposed openstack/keystone: Add id to conflict error if caused by duplicate id https://review.openstack.org/409010 | 08:19 |
| openstackgerrit | Shan Guo proposed openstack/keystone: Fix typo in api-ref doc https://review.openstack.org/409011 | 08:19 |
| *** tobberydberg has joined #openstack-keystone | 08:20 | |
| *** tobberyd_ has joined #openstack-keystone | 08:27 | |
| *** tobberydberg has quit IRC | 08:30 | |
| *** tobberyd_ has quit IRC | 08:32 | |
| *** henrynash has joined #openstack-keystone | 08:37 | |
| *** ChanServ sets mode: +v henrynash | 08:37 | |
| *** henrynash has quit IRC | 08:52 | |
| *** udesale has joined #openstack-keystone | 08:54 | |
| *** udesale has quit IRC | 08:54 | |
| *** udesale has joined #openstack-keystone | 08:55 | |
| *** udesale has quit IRC | 08:56 | |
| *** udesale has joined #openstack-keystone | 08:57 | |
| *** tobberydberg has joined #openstack-keystone | 08:58 | |
| *** tobberydberg has quit IRC | 08:59 | |
| *** zzzeek has quit IRC | 09:00 | |
| *** tobberydberg has joined #openstack-keystone | 09:00 | |
| *** zzzeek has joined #openstack-keystone | 09:00 | |
| *** namnh has joined #openstack-keystone | 09:05 | |
| *** tqtran has joined #openstack-keystone | 09:36 | |
| *** tqtran has quit IRC | 09:40 | |
| *** GB21 has joined #openstack-keystone | 09:49 | |
| *** davechen has quit IRC | 09:56 | |
| *** eandersson has quit IRC | 10:03 | |
| *** liujiong has quit IRC | 10:06 | |
| *** zhangjl has left #openstack-keystone | 10:21 | |
| *** tovin07 has quit IRC | 10:22 | |
| *** guoshan has quit IRC | 10:24 | |
| *** hoangcx has quit IRC | 10:30 | |
| *** GB21 has quit IRC | 10:39 | |
| openstackgerrit | Julia Varlamova proposed openstack/keystone: Change DevStack plugin to setup multi-Keystone https://review.openstack.org/399472 | 10:40 |
| *** jaosorior is now known as jaosorior_lunch | 11:00 | |
| *** GB21 has joined #openstack-keystone | 11:01 | |
| *** richm has joined #openstack-keystone | 11:11 | |
| *** madhaviy has quit IRC | 11:13 | |
| *** henrynash has joined #openstack-keystone | 11:21 | |
| *** ChanServ sets mode: +v henrynash | 11:21 | |
| *** madhaviy has joined #openstack-keystone | 11:22 | |
| *** spzala has joined #openstack-keystone | 11:24 | |
| *** spzala has quit IRC | 11:29 | |
| *** nicolasbock has joined #openstack-keystone | 11:35 | |
| *** david-lyle_ has joined #openstack-keystone | 11:35 | |
| *** tqtran has joined #openstack-keystone | 11:37 | |
| *** tsufiev has left #openstack-keystone | 11:37 | |
| *** david-lyle has quit IRC | 11:37 | |
| *** tqtran has quit IRC | 11:41 | |
| *** edmondsw has joined #openstack-keystone | 11:47 | |
| *** jaosorior_lunch is now known as jaosorior | 11:55 | |
| *** edmondsw_ has joined #openstack-keystone | 12:02 | |
| *** henrynash has quit IRC | 12:02 | |
| *** edmondsw_ has quit IRC | 12:03 | |
| *** dikonoor has joined #openstack-keystone | 12:09 | |
| *** dave-mccowan has joined #openstack-keystone | 12:09 | |
| *** guoshan has joined #openstack-keystone | 12:10 | |
| *** namnh has quit IRC | 12:12 | |
| *** zhangjl has joined #openstack-keystone | 12:14 | |
| *** raildo has joined #openstack-keystone | 12:17 | |
| dikonoor | stevemar: Hi Steve.. | 12:22 |
| dikonoor | stevemar: I am looking on information related to http://www.gossamer-threads.com/lists/openstack/operators/44312 | 12:23 |
| dikonoor | stevemar: basically on if the community has arrived at any conclusion on how to deal with resource clean up when project is deleted | 12:23 |
| dikonoor | ayoung: dolphm: anyone has the latest on this ? | 12:24 |
| breton | dikonoor: nothing has actually been implemented | 12:25 |
| breton | dikonoor: people use ospurge sometimes | 12:25 |
| dikonoor | breton : ok.. So anyone who wants to go about with the clean up has the option to use only ospurge. Are there any blueprints or anything else planned ? | 12:26 |
| *** jamielennox is now known as jamielennox|away | 12:33 | |
| breton | dikonoor: i'd say there is nothing until someone actively works on it. I don't know anybody who would work in it. | 12:35 |
| dikonoor | breton : ok.. | 12:37 |
| dikonoor | breton : A similar problem would happen with userid as well | 12:38 |
| dikonoor | Do you know if orpurge handles that as well ? | 12:38 |
| *** GB21 has quit IRC | 12:40 | |
| breton | dikonoor: don't know | 12:40 |
| *** zhangjl has quit IRC | 12:50 | |
| *** pcaruana has quit IRC | 13:05 | |
| *** pcaruana has joined #openstack-keystone | 13:08 | |
| samueldmq | morning keystone | 13:10 |
| *** asettle has quit IRC | 13:18 | |
| *** asettle has joined #openstack-keystone | 13:19 | |
| ayoung | dikonoor, it is an intractable problem. We do not know all of the systems out there, or what resources they have, nor what is the safe way to delete them. The only approach would be to reguster tasks with something like mistral that are run based on notifications from Keystone | 13:24 |
| *** maestropandy has joined #openstack-keystone | 13:31 | |
| *** maestropandy has left #openstack-keystone | 13:31 | |
| *** maestropandy has joined #openstack-keystone | 13:39 | |
| *** maestropandy has left #openstack-keystone | 13:39 | |
| *** tqtran has joined #openstack-keystone | 13:39 | |
| *** tqtran has quit IRC | 13:43 | |
| openstackgerrit | Samuel Pilla proposed openstack/keystone: API Documentation for user password expires https://review.openstack.org/405574 | 13:44 |
| openstackgerrit | Julia Varlamova proposed openstack/keystone: Change DevStack plugin to setup multi-Keystone https://review.openstack.org/399472 | 13:49 |
| *** boris-42 has quit IRC | 13:51 | |
| *** spzala has joined #openstack-keystone | 13:51 | |
| *** boris-42 has joined #openstack-keystone | 13:51 | |
| *** narasimha_SV_ has joined #openstack-keystone | 13:58 | |
| edmondsw | ayoung dstanek lbragstad stevemar I added my comments to https://review.openstack.org/#/c/391624 | 13:58 |
| ayoung | edmondsw, I saw. I was just about to address | 13:58 |
| edmondsw | just finished, so there are more than what I saved yesterday | 13:59 |
| ayoung | edmondsw, details aside, when we discussed you were pretty set against it. | 13:59 |
| edmondsw | I wouldn't say that | 13:59 |
| edmondsw | I am very against certain portions, but not most of it | 13:59 |
| ayoung | edmondsw, well, the whole thing has to fall together in order to work. Is there anything there that you feel absolutely must be changed, and how? | 14:00 |
| *** daemontool has joined #openstack-keystone | 14:00 | |
| edmondsw | one is that you have to allow multiple roles per API | 14:01 |
| edmondsw | there's no reason to restrict that to a singe role | 14:01 |
| edmondsw | there are plenty of reasons not to | 14:01 |
| ayoung | edmondsw, OK lets start there | 14:01 |
| *** lunarlamp is now known as mariusv | 14:02 | |
| edmondsw | ayoung go through the comments let's whittle them down... there are a bunch of things that should just be simple edits for you, like fixing spelling or clarifying something | 14:02 |
| ayoung | edmondsw, I can do that, but I want to address the "stop ship" elements | 14:02 |
| ayoung | edmondsw, I originally had it as multiple roles. It is possible to do, just adds a slew of complexity, but that was not the real reason | 14:03 |
| edmondsw | absolutely... when you go through the comments and come to one of those, if what I said in the comment didn't convince you, ping me and we'll talk | 14:03 |
| edmondsw | what complexity does it add? | 14:03 |
| edmondsw | kinda seems the opposite to me... | 14:03 |
| ayoung | edmondsw, so one goal here is to provide a means to delegate to a subset of operations. And in order to do that, there needs to be some hierarchy from the roles a user is assigned to the roles that map to an operation. Today that mapping is direct. | 14:04 |
| ayoung | I want to add exactly one mechanism for indirect mapping | 14:04 |
| edmondsw | I could tell you must have originally had it as multiple roles, because several of my comments were "hey, this is a place that still says multiple roles :)" | 14:04 |
| ayoung | so your big complaint, as I understand it, is that adding additional "roles" messes up UX | 14:05 |
| edmondsw | ayoung "exactly one mechanism for indirect mapping" ? | 14:05 |
| edmondsw | ayoung, that would be one argument | 14:05 |
| ayoung | edmondsw, right. If we put two or more roles directly into the map for an operation, we have 2 mechanisms; | 14:05 |
| narasimha_SV_ | any one working on LDAP integration for keystone ????????????????? | 14:06 |
| ayoung | edmondsw, and, you commented that "roles" are actually "permissions" | 14:06 |
| ayoung | narasimha_SV_, many people, but hold on for a moment, please | 14:06 |
| edmondsw | they should not be... you seem to be confusing the two in places | 14:06 |
| ayoung | edmondsw, the permission is what I am currently callin an api_role: this role allows access to this api. | 14:07 |
| ayoung | I didn;t want to use the term "permission" because | 14:07 |
| ayoung | it has the potential to be wrong | 14:07 |
| ayoung | the permission is also what the policy file allows | 14:07 |
| rodrigods | knikolla, hey... think that for the federation plugin we just need to export the configs for the tempest plugin test and we are done | 14:07 |
| ayoung | and might even be a lower level thing than that... | 14:07 |
| edmondsw | ayoung right... api_role is part of a permission | 14:08 |
| *** hrybacki has quit IRC | 14:08 | |
| ayoung | right "part" | 14:08 |
| *** hrybacki has joined #openstack-keystone | 14:08 | |
| ayoung | I also did not want to introduce a new concept, nor rename an existing one | 14:08 |
| ayoung | I don't think I would have picked "role" from a blank slate | 14:08 |
| ayoung | henry's domain specific roles are more like traditional roles | 14:08 |
| edmondsw | ayoung not sure where you're going here... | 14:08 |
| ayoung | the roles as implemented here are the middle layer of indirection | 14:09 |
| ayoung | but I stuck with the term | 14:09 |
| ayoung | edmondsw, one big goal here is delegation | 14:09 |
| ayoung | I want someone to be able to say "I have the member role, but I want to be able to delegate just the ability to reboot a virtual machine" | 14:09 |
| edmondsw | sure... but allowing/supporting delegation does not mean you have to require there only be one role allowed to do something | 14:10 |
| ayoung | if we say "rebooting a virtual machine requires either the member role or the reboot role" there is not relationship between the two, and you cannot delegate just that smaller role, or just that operation | 14:10 |
| ayoung | it is the relationship that is important | 14:10 |
| edmondsw | ayoung wait and let me answer that | 14:11 |
| edmondsw | there's really no problem there | 14:11 |
| ayoung | so, providing a middle layer, that can be changed without breaking existing workflows is essential | 14:11 |
| ayoung | and without having to explicitly assign new roles to everyone in order for them to delegate | 14:11 |
| ayoung | lots of constraints here. | 14:11 |
| ayoung | Go ahead | 14:11 |
| edmondsw | I'm not saying you can't create a new compute_server_delete role if you want, and make that implied by member, and then update api_roles to refer to that. I'm saying you shouldn't HAVE TO | 14:12 |
| *** agrebennikov_ has joined #openstack-keystone | 14:12 | |
| edmondsw | make sense? | 14:12 |
| edmondsw | ayoung ^ | 14:14 |
| ayoung | edmondsw, I think I would like you to be more explicit on what the problems are of requiring that | 14:14 |
| ayoung | where would it mess people up. | 14:14 |
| ayoung | ignoring the UX issue. | 14:14 |
| ayoung | We can solve UX a different way if it proves to be a problem | 14:15 |
| edmondsw | if I want to use implied roles and then have api_roles simplified down to a single role, great. Someone else should be allowed to instead specify multiple roles in their api_roles rule | 14:15 |
| edmondsw | keystonemiddleware shouldn't care which approach you want to take | 14:15 |
| edmondsw | by making it a list, you leave that up to the deployers to decide | 14:15 |
| edmondsw | so problems or requiring a single role: | 14:16 |
| edmondsw | 1) you now require folks who have multiple roles that need to do x to have all those roles linked in an implied role hierarchy... which may deployers (e.g. me) will not be able to do without creating a bunch more roles than they have today to serve as intermediaries | 14:17 |
| edmondsw | more roles leads to a lot of problems. If you want to take those on in your deployment, be my guest, but I don't want to do that in mine | 14:18 |
| edmondsw | more roles leads to the problems you alluded to in the spec with larger token responses. It leads to worse UX, etc. | 14:18 |
| edmondsw | narasimha_SV go ahead and throw out your question | 14:20 |
| ayoung | edmondsw, so that, to me, all resolves to UX | 14:20 |
| ayoung | if we could hide the lowest level roles from the normal UX flow, the mechanism would be the same | 14:21 |
| edmondsw | larger token responses leads to perf issues, code complexity... not just UX | 14:21 |
| ayoung | edmondsw, so, not in the token | 14:21 |
| ayoung | the implied roles will only get expanded in the api_role fetch | 14:21 |
| edmondsw | I don't think you can hide them effectively | 14:21 |
| edmondsw | ayoung I addressed why that won't work in my comments | 14:22 |
| edmondsw | breaks the caching model | 14:22 |
| ayoung | edmondsw, if we tag a role as 'internal' and say that list_roles does not show them unless you pass internal=true | 14:22 |
| ayoung | edmondsw, you mean because someone could update the roles and the fetch would not know about them until next fetch? | 14:22 |
| edmondsw | no | 14:23 |
| *** andrewbogott has quit IRC | 14:23 | |
| *** andrewbogott has joined #openstack-keystone | 14:23 | |
| *** andrewbogott has quit IRC | 14:23 | |
| *** andrewbogott has joined #openstack-keystone | 14:23 | |
| edmondsw | ayoung, oh, maybe I'm wrong about the caching issue... | 14:24 |
| edmondsw | the cached token would have some role, e.g. compute_delete_server | 14:25 |
| ayoung | edmondsw, one question, though, is do you really envision the need to delegate each individual operation? I suspect that what we really are going to have is a handful of operations that need to be isolated, but most would be OK with "Member". I just don't want to build too much mechanism up front: I'd rather let the complexity emerge | 14:26 |
| edmondsw | but whatever checks the cache to see if a token it has is valid should be ok if it doesn't look at the role on the cached token... it should only look at the role on the token it actually received | 14:26 |
| ayoung | If it turns out that we do need multiple, non-implied roles per API we can relax the uniqueness constraint on the API portion: | 14:27 |
| edmondsw | ayoung remember that I don't even have a member role | 14:27 |
| ayoung | that GET + VERB has to be unique | 14:27 |
| ayoung | edmondsw, I did not know that. | 14:27 |
| ayoung | edmondsw, you have to give me some sense of your layout if you want me to take your setup into account. | 14:28 |
| edmondsw | thought I said that the other day... I have admin, deployer, viewer, vm_manager, vm_user, image_manager, project_manager, storage_manager, etc. | 14:28 |
| edmondsw | e.g. vm_user can only work with an existing VM (start, stop, that kind of thing) but can't actually create/delete it, etc. | 14:29 |
| ayoung | edmondsw, so you have a manager role per service, or is it per resource? | 14:30 |
| edmondsw | no, I don't have a role per service | 14:30 |
| ayoung | well, storage_manager is cinder specific, I assume | 14:31 |
| edmondsw | close, but not quite | 14:31 |
| ayoung | edmondsw, so is it "reader" that messes you up, as it is a cross cutting concern? | 14:31 |
| ayoung | i.e. storage_manager should not be able to read vm's etc? | 14:32 |
| edmondsw | a lot of them are cross-cutting | 14:32 |
| edmondsw | right storage_manager doesn't have access to VMs | 14:32 |
| ayoung | so for reader, my approach would force you to create vm_reader, and then reader implies vm_reader, storage_reader etc | 14:33 |
| ayoung | a bunch of roles that you would not assign on their own | 14:33 |
| edmondsw | but then what do I do about storage_manager? | 14:34 |
| ayoung | storage_manager would imply storage_reader | 14:35 |
| ayoung | its a DAG, not a strict hierarchy | 14:35 |
| edmondsw | that might work for the reader stuff | 14:37 |
| edmondsw | I think I've have more issues with other cases | 14:37 |
| edmondsw | lots of rules are currently "role:x or role:y or role:z" but then another place is "role:x or role:y or role:a", etc. | 14:38 |
| edmondsw | I can try to find a way to map those out using implied roles and see what I can come up with... that's a todo for me | 14:39 |
| edmondsw | but I still don't understand your reluctance to just allow multiple roles api_roles | 14:39 |
| edmondsw | I don't see how that adds complexity as you claim | 14:39 |
| *** dikonoor has quit IRC | 14:39 | |
| ayoung | edmondsw, it was as I was going through the implementation details | 14:42 |
| *** pcaruana has quit IRC | 14:42 | |
| edmondsw | ayoung can you elaborate? | 14:43 |
| ayoung | yeah...one sec...making coffee, too | 14:43 |
| edmondsw | this should be spelled out in the alternatives section | 14:43 |
| ayoung | edmondsw, so I think that "multiple explicit roles per api" is possible as a follow on to this spec without too much extra work | 14:44 |
| ayoung | it started with me having APIs top manage two objects, and it was confusing | 14:44 |
| ayoung | if it was confusing to me, imaging how it would be to new users | 14:44 |
| edmondsw | ayoung then there must not be any reason not to just do it in this spec ;0 | 14:44 |
| ayoung | well, hold on | 14:44 |
| edmondsw | "APIs to manage two objects" ?? | 14:44 |
| *** GB21 has joined #openstack-keystone | 14:45 | |
| ayoung | yeah, the two objects were | 14:45 |
| ayoung | 1. the API objkect | 14:45 |
| ayoung | VERB + URL | 14:45 |
| ayoung | VERB + URL + SERVER actually | 14:45 |
| ayoung | the second was API to Role | 14:45 |
| edmondsw | why is that 2nd an object at all? | 14:45 |
| ayoung | edmondsw, so, if I loosened that constraint, made it possible to have multiple roles explicitly assigned to the API, that would address your biggest concern? | 14:46 |
| edmondsw | why isn't the role infomation in the first object, so you only have one object? | 14:46 |
| edmondsw | ayoung I think that was the biggest, now let me go back and check again | 14:46 |
| ayoung | edmondsw, yes, that is a better implementation | 14:46 |
| ayoung | edmondsw, OK, I think I can make that work. It means that we need decent semantics for how to remove/change api_roles | 14:47 |
| edmondsw | ayoung another objection was the inclusion of admin_project_only. That is a scope check and you lay this out as specifically being only a role check and leaving scope to the services to work out | 14:47 |
| edmondsw | if we understand admin_project_only is a hack but really want to do it anyway for some reason, those reasons need to be clearly spelled out. And I would argue it should be a separate spec | 14:49 |
| ayoung | edmondsw, yeah. I waffled on that | 14:49 |
| ayoung | I *think* we can safely remove that | 14:49 |
| edmondsw | cool | 14:49 |
| edmondsw | another was my comment at line 182 | 14:49 |
| *** cargonza has quit IRC | 14:50 | |
| edmondsw | the action APIs are a good example of where middleware role checks will not really do any good. Doesn't mean we can't do it for everything else's sake, but we should understand that policy.json/yaml editing will still be necessary for those | 14:50 |
| *** cargonza has joined #openstack-keystone | 14:50 | |
| ayoung | edmondsw, agreed | 14:50 |
| edmondsw | I'd want some words about that in the spec | 14:51 |
| ayoung | a lot of stuff done in policy.json is outside of RBAC. I was not trying to solve everything here | 14:51 |
| edmondsw | so people understand | 14:51 |
| edmondsw | yeah, but this touches on what you ARE trying to solve :) | 14:51 |
| edmondsw | which is why I think it should just be discussed | 14:51 |
| edmondsw | no implementation changes, just discussed | 14:51 |
| edmondsw | ayoung another thing was in one place (line 241) you mentioned there would be new headers, but didn't say what or why... I don't see the need... what were you thinking there? | 14:52 |
| ayoung | edmondsw, yeah. that confused people before too. That is explaining what actually happens today | 14:53 |
| ayoung | they are not new headers, that is how Middleware communicates with the follow on layer | 14:53 |
| ayoung | with the service | 14:53 |
| *** raddaoui has quit IRC | 14:53 | |
| edmondsw | so just some clarification needed there it sounds like | 14:53 |
| *** raddaoui has joined #openstack-keystone | 14:53 | |
| ayoung | "there is no change" was my last attempt to do that. | 14:54 |
| ayoung | I'll try again | 14:54 |
| edmondsw | ayoung there were some comments around the way we handle defaults | 14:54 |
| ayoung | edmondsw, one possibility there | 14:54 |
| ayoung | we could hook into the service catalog API | 14:54 |
| ayoung | when a service is created, we push in a default api_role based on the default role set in the keystone.conf | 14:55 |
| edmondsw | I think that it should not be necessary to set api_roles for every service before you can start using this... one should be sufficient and any service which doesn't have api_roles set just works as it does today | 14:55 |
| edmondsw | i.e., the default when you haven't explicitly set a default is to allow all | 14:55 |
| ayoung | well, if they don't enable the RBAC check in the config file, it will. But you are saying if they enable it, but have not posted any specific api_roles, it should still work | 14:55 |
| ayoung | OK, here is what I was thinking | 14:56 |
| ayoung | we have a default api_role like this: | 14:56 |
| andreaf | Around Nov 20 the identity v2 own pwd reset test suddenly started taking almost double as run http://status.openstack.org/openstack-health/#/test/tempest.api.identity.v2.test_users.IdentityUsersTest.test_user_update_own_password - I was looking for a change in Tempest that could explain but I found nothing - does this ring a bell to anyone? | 14:56 |
| *** pcaruana has joined #openstack-keystone | 14:56 | |
| andreaf | The matching v3 test is ok http://status.openstack.org/openstack-health/#/test/tempest.api.identity.v3.test_users.IdentityV3UsersTest.test_user_update_own_password | 14:56 |
| ayoung | SERVICE: ANY, PATTERN:ANY, ROLE:None. When we fetch for a service, and there are no specific api_roles for that service, append that one instead | 14:57 |
| ayoung | edmondsw, I think that has the effect you are looking for | 14:57 |
| *** AndyWojo has quit IRC | 14:58 | |
| *** AndyWojo has joined #openstack-keystone | 14:58 | |
| edmondsw | I actually liked your "default" in the example at line 199 better than that ANY stuff at line 267 | 14:58 |
| ayoung | the thing I don't like is that, if we do multiple api_roles per API, we have to OR them together. This one would be "AND NOT" | 14:58 |
| edmondsw | but yeah | 14:58 |
| ayoung | we need the ANY stuff, too | 14:58 |
| edmondsw | the ANY would be implicit, and understood in code | 14:59 |
| edmondsw | removes the issues of a user mucking with it | 14:59 |
| edmondsw | default == ANY... it can't equal anything else | 14:59 |
| ayoung | edmondsw, but a sysadmin might need to remove that later for compliance | 14:59 |
| *** links has quit IRC | 14:59 | |
| edmondsw | "multiple api_roles together" ? | 15:00 |
| ayoung | would rather not make it hard coded | 15:00 |
| ayoung | edmondsw, OK...so impl detai | 15:00 |
| ayoung | say GET /v2/thing is Member to start | 15:00 |
| ayoung | and you want a thingy role | 15:00 |
| ayoung | so you could add an additional api_role | 15:00 |
| edmondsw | I'm not saying you can't change the default... you certainly can, as line 199 would allow... you can't just change what the definition of default is... default's definition is ANY verb, ANY pattern | 15:01 |
| ayoung | GET /v2/thing would then return roles [Member, thingy] | 15:01 |
| ayoung | I do want per service defaults, and a global too | 15:01 |
| edmondsw | absolutely | 15:01 |
| edmondsw | line 199 allows for that | 15:01 |
| ayoung | we need a way to admin it, too, though | 15:02 |
| ayoung | OK, I think I need 2 variations on the bulk fetch API | 15:03 |
| ayoung | 1 used for enforcement, one for admin | 15:03 |
| edmondsw | ? | 15:03 |
| ayoung | implementation detail | 15:03 |
| ayoung | I want to be able to distinguish between | 15:03 |
| ayoung | 321abc GET /v2/thing and 987bcd GET /v2/thing | 15:04 |
| ayoung | If I want to delete only | 15:04 |
| ayoung | 987bcd GET /v2/thing role:thingy | 15:04 |
| edmondsw | what are 321abc and 987bcd there? | 15:04 |
| ayoung | I should be able to to that | 15:04 |
| ayoung | those are the api_role['id'] values | 15:04 |
| edmondsw | why would there be 2 for the same API? | 15:05 |
| ayoung | edmondsw, so there is def a need to specify the upgrade workflow here | 15:05 |
| ayoung | what do we do when a new version of nova comes out with more apis | 15:05 |
| edmondsw | list that under deployer impacts | 15:05 |
| *** tobberyd_ has joined #openstack-keystone | 15:06 | |
| edmondsw | they would need to understand that the default rule will be used for new APIs until they specify an explicit rule | 15:06 |
| ayoung | id: 987bcd verb:GET /pattern:v2/thing role:thingy vs id:321abc verb:GET pattern:/v2/thing role:member | 15:06 |
| edmondsw | no no no | 15:07 |
| edmondsw | 987bcd verb:GET /pattern:v2/thing role:['thingy','member'] | 15:07 |
| ayoung | but then your workflow needs to know the existing roles in order to be able to update it | 15:07 |
| edmondsw | not necessarily | 15:08 |
| ayoung | PATCH | 15:08 |
| *** tobberydberg has quit IRC | 15:09 | |
| edmondsw | use POST and have the body specify what you want to remove from where | 15:09 |
| ayoung | PATCH /v3/api_role/987bc body={role: member} | 15:09 |
| ayoung | or better | 15:09 |
| *** henrynash has joined #openstack-keystone | 15:09 | |
| *** ChanServ sets mode: +v henrynash | 15:09 | |
| ayoung | PATCH /v3/api_role/987bc body={add_roles: [member], delete_roles:[thingy]} | 15:09 |
| ayoung | but nothing we have works like that now | 15:09 |
| *** tobberyd_ has quit IRC | 15:10 | |
| edmondsw | ayoung I would suggest that the global default be to allow all (so that it's ok if you're not setting api_roles on some services), but that the project-specific default (if they create api_roles for that project but don't specify a default) be admin | 15:13 |
| ayoung | edmondsw, trying to avoid POST except for creating a new one | 15:13 |
| edmondsw | ayoung yeah, if you use POST it would need to be something like /v3/api_roles/edit and I'm not a huge fan but it can work | 15:14 |
| edmondsw | if you can make PATCH work, that's probably better | 15:14 |
| ayoung | edmondsw, Yeah, my understanding is that, on a given api_role PUT should erase the old set of roles and replace with the given set. PATCH should allow modifications of the set by element. | 15:16 |
| ayoung | DELETE should remove the whole pattern | 15:16 |
| edmondsw | ayoung that is correct. It's not how OpenStack does things, but it's how REST is supposed to work :) | 15:16 |
| *** henrynash has quit IRC | 15:16 | |
| *** pkoraca has quit IRC | 15:17 | |
| edmondsw | I should say it's not how MOST OpenStack APIs work... a few do | 15:17 |
| edmondsw | and more power to them, and we should add to that list | 15:17 |
| *** henrynash has joined #openstack-keystone | 15:17 | |
| *** ChanServ sets mode: +v henrynash | 15:17 | |
| *** pkoraca has joined #openstack-keystone | 15:17 | |
| ayoung | edmondsw, so, omne thing I need to sort is to make it clear which are explicitly assigned roles and which are implied. | 15:17 |
| *** henrynash has quit IRC | 15:18 | |
| ayoung | the use case is "I want to know what roles I need to delegate to someone else in order to perform this operation" | 15:18 |
| ayoung | ideally, you would pass the complete URL (or the section) to Keystone and it would pass you back the roles, but I think doing a fetch and a match to start makes sense | 15:19 |
| edmondsw | you mean fetch the whole list of api_roles? | 15:20 |
| *** clsacramento has quit IRC | 15:24 | |
| *** robcresswell has quit IRC | 15:24 | |
| *** robcresswell has joined #openstack-keystone | 15:25 | |
| *** lamt has joined #openstack-keystone | 15:25 | |
| *** guoshan has quit IRC | 15:26 | |
| ayoung | edmondsw, for a service | 15:27 |
| ayoung | edmondsw, same as the middleware would have to do to enforce | 15:27 |
| edmondsw | yeah... I agree that ideally you'd be able to just specify which URL you want to know about, but fetching the whole thing might be ok to start with | 15:28 |
| edmondsw | would want to write the code that does the fetch/match in such a way that other things could use it, for cases like this | 15:29 |
| edmondsw | I think we went through my most significant comments. Progress! | 15:29 |
| dstanek | ayoung: why is url better than just the operation? like nova:boot_vm | 15:32 |
| *** chris_hultin|AWA is now known as chris_hultin | 15:33 | |
| *** daemontool has quit IRC | 15:33 | |
| *** ravelar has joined #openstack-keystone | 15:34 | |
| *** jaosorior has quit IRC | 15:35 | |
| *** narasimha_SV_ has quit IRC | 15:41 | |
| *** ravelar has quit IRC | 15:42 | |
| *** chris_hultin is now known as chris_hultin|AWA | 15:43 | |
| edmondsw | dstanek I assumed it's because the middleware is told the URL, and wouldn't know how to map that to nova:boot_vm | 15:43 |
| edmondsw | ayoung ^ | 15:44 |
| dstanek | edmondsw: something has to map url to operation though...and i don't think it should be the cloud admin doing that in keystone | 15:44 |
| dstanek | i'd rather a service have to be responsible for maintaining that map | 15:44 |
| edmondsw | it's not | 15:44 |
| edmondsw | the service is doing that | 15:44 |
| edmondsw | even without this middleware, the service does that today, right? | 15:45 |
| dstanek | edmondsw: as an admin if i was to change the role used for an operation i have to know the url and http method | 15:45 |
| edmondsw | that wouldn't change | 15:45 |
| edmondsw | yes | 15:45 |
| edmondsw | which you would know, right? | 15:45 |
| dstanek | i think that's terrible and violates REST | 15:45 |
| edmondsw | because the APIs is how you interact with the service... that's the contract | 15:45 |
| dstanek | i don't know that now, but i can change policy | 15:46 |
| edmondsw | if you want to use something like boot_vm, that "boot_vm" is actually something new that the user won't understand and will have to lookup which API that maps to | 15:46 |
| edmondsw | dstanek policy should have also worked this way... the fact that it doesn't is a knock on the guys that implemented policy | 15:46 |
| edmondsw | they weren't thinking about UX, clearly | 15:47 |
| *** chris_hultin|AWA is now known as chris_hultin | 15:47 | |
| dstanek | why do i ever have to know the URL. in a real RESTful system the URLs could change | 15:47 |
| *** ravelar has joined #openstack-keystone | 15:48 | |
| edmondsw | the only time YOU don't have to know the URL if is you use some client that abstracts that away from you | 15:48 |
| edmondsw | the contract is and always has been the URL | 15:48 |
| edmondsw | and is in every RESTFUL system | 15:48 |
| edmondsw | that's what makes it RESTful... that the REST API is the contract | 15:48 |
| dstanek | edmondsw: actually that's not true the only URL that should be hardcoded is entry points all other urls should be followed via relationships - what when do is not REST | 15:49 |
| edmondsw | no... relationships are great but they are optional, not required | 15:49 |
| dstanek | HATEOAS is mostly clear on this subject | 15:50 |
| edmondsw | and I don't think there's any system where you only need to know one entry point URL | 15:50 |
| ayoung | dstanek, sorry, missed the notification. THere is no way to make compute:start_server to the URL that executes it. A user does not know what policy rule is going to be executed | 15:50 |
| dstanek | edmondsw: how about every website ever? | 15:50 |
| edmondsw | websites are not in any sense RESTful | 15:50 |
| dstanek | edmondsw: that is what Ray based his research on | 15:51 |
| dstanek | Roy* | 15:51 |
| dstanek | ayoung: they don't know what operation they are protecting? | 15:51 |
| edmondsw | I'm pretty sure Roy would agree with me on this... websites are not RESTful | 15:51 |
| ayoung | ideally, there would be "query role for this API" verb that would say "assuimg the resource you want exists, this is the role you would need to execute against it" | 15:51 |
| edmondsw | I've read Roy's stuff... I don't think I'm diverging from him here | 15:52 |
| dstanek | edmondsw: what we do is like uri templating and that's normally frowned upon...but we do it much, much worse because the template isn't in the body of the response it's in the client | 15:53 |
| edmondsw | ayoung, i.e. a permissions API :) | 15:53 |
| ayoung | edmondsw, a persmissions verb specifically | 15:53 |
| edmondsw | dstanek we do a lot of bad things... like using PUT to update when it's supposed to be replace | 15:53 |
| *** pece has joined #openstack-keystone | 15:54 | |
| ayoung | so instead of GET /v3/users/<userID> I could do QUERY v3/users/<userID> and get back {roles: [a,bn c] | 15:54 |
| *** catintheroof has joined #openstack-keystone | 15:54 | |
| dstanek | ayoung: why is making me know the URL better than knowing i'm doing an identity:get_user? | 15:55 |
| *** tesseract- has quit IRC | 15:56 | |
| knikolla | rodrigods: awesome! let's get it done. | 15:56 |
| ayoung | dstanek, because you always know the URL you are trying to execute | 15:56 |
| ayoung | you can run openstack <op> --debug and figure it op | 15:57 |
| ayoung | out | 15:57 |
| dstanek | edmondsw: an oldy, but goody http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven | 15:57 |
| *** edtubill has joined #openstack-keystone | 15:58 | |
| dstanek | edmondsw: short, short is that if a client knows URLs beyond a handful on entry points then you are doing it wrong | 15:58 |
| ayoung | dstanek, we could even build the matching capability into keystone client... | 15:58 |
| ayoung | Hmmm | 15:58 |
| ayoung | discoverability...one of his big points there | 15:59 |
| ayoung | "A REST API must not define fixed resource names or hierarchies " | 15:59 |
| ayoung | I pushed for that in Keystone a few years back, that was the whole "keystone should do HTML" thing | 15:59 |
| dstanek | ayoung: i don't care about HTML specifically, but conceptually that's a great idea | 16:00 |
| edmondsw | dstanek, I'm reading... haven't gotten to anything like that yet | 16:00 |
| ayoung | dstanek, HTML was just a way to make people see it | 16:00 |
| dstanek | edmondsw: last bullet is that specific point | 16:01 |
| ayoung | dstanek, Ideally, in an OpenStack system, the user has an AUTH URL, and discovers everything else from there. | 16:01 |
| dstanek | A REST API should be entered with no prior knowledge beyond the initial URI (bookmark) | 16:01 |
| edmondsw | dstanek, found it... | 16:01 |
| edmondsw | so then forget calling this REST :) | 16:02 |
| edmondsw | ever | 16:02 |
| dstanek | with REST there are tradeoffs, but wouldn't it be great if a client could contact keystone and just navigate links? | 16:02 |
| dstanek | this client wouldn't have to be intelligent at all, just scripted | 16:02 |
| edmondsw | if this is not and never will be REST, then what Roy says about REST can be ignored here | 16:02 |
| dstanek | edmondsw: i've said that since i started working on openstack. we are an HTTP RPC API | 16:02 |
| edmondsw | yep | 16:03 |
| dstanek | that highlights my point nicely.... i can create policy right now for nova by having a list of operations. i have no idea what the URLs are and i don't care. what i am hearing now is that you want me to care | 16:04 |
| edmondsw | dstanek no, you can't | 16:05 |
| edmondsw | you can't create policy for nova without digging through nova's code... I know, I've had to do it :( | 16:05 |
| ayoung | dstanek, OK...so, lets assume that is the goal here. Now, add in delegation. How can a user discover what she needs to delegate to another user in order to have that other user perform an operation on her behalf? | 16:05 |
| dstanek | what operation is 'GET /blah' vs. 'PUT /blah' vs. 'PATCH /blah' vs. 'POST /blah' | 16:05 |
| ayoung | edmondsw, +++++++ | 16:05 |
| ayoung | edmondsw, that is a huge driving point behind the RBAC spec | 16:05 |
| dstanek | ayoung: in your world what would a user have to know? | 16:06 |
| edmondsw | dstanek I've spent hours trying to figure out where a policy setting is actually being checked in code to determine what it's really for | 16:06 |
| dstanek | edmondsw: so in practice you are looking at the URLs? | 16:06 |
| edmondsw | yes | 16:06 |
| edmondsw | if i understand the questionm | 16:06 |
| ayoung | dstanek, so, with RBAC, everything is a role. If you have an operation that requires a role, you delegate only that role | 16:06 |
| *** rcernin has quit IRC | 16:07 | |
| ayoung | and, in my world operation={URL + VERB} | 16:07 |
| openstackgerrit | Merged openstack/keystone: Fix typo in api-ref doc https://review.openstack.org/409011 | 16:09 |
| ayoung | dstanek, as edmondsw pointed out earlier, however, Nova has some cases where it hides the operation inside the payload of the PUT/POST body | 16:09 |
| dstanek | ayoung: so pretend we have an awesome GUI for delegation. i would expect to see a nice list of responsibilites that can be deletegated (boot, shutdown, snapshot, whatever) right? | 16:09 |
| dstanek | users will never see URLs in that case | 16:10 |
| ayoung | dstanek, that is a UI decision, how to present. Take it back a step | 16:10 |
| ayoung | say you want to do this from Pythong | 16:10 |
| ayoung | Python | 16:10 |
| *** spligak has quit IRC | 16:10 | |
| ayoung | and you know "thit API is from nova client" | 16:10 |
| ayoung | how do you figure out what to delegate? | 16:11 |
| ayoung | one option could be that you have the execption hander call into keystoneclient with the URL it tried | 16:11 |
| dstanek | ayoung: i have a list of things you can do to a resource and i pick from the list | 16:11 |
| *** chlong has joined #openstack-keystone | 16:11 | |
| ayoung | and keystone client looks it up in the keystone API | 16:11 |
| dstanek | i don't care about the client directly | 16:11 |
| *** chlong has quit IRC | 16:12 | |
| *** chlong has joined #openstack-keystone | 16:12 | |
| ayoung | dstanek, that was exactly the use case david-lyle_ asked me about at the SUmmit several years back that lead to this approach | 16:12 |
| dstanek | it would actually be super awesome if the OSC commands perfectly aligned with the operation in policy and documentation | 16:12 |
| ayoung | he wanted to know: based on the roles that a user has, what should I show her? | 16:12 |
| dstanek | sure, probably so he can have certain buttons like 'reboot' appear based on that role | 16:13 |
| dstanek | definitely not a 'POST /vm/{id}/something/reboot' button | 16:14 |
| dstanek | my general point is that services already need to know their URLs and how that maps to operations. why does anyone else have to care? | 16:15 |
| ayoung | dstanek, because first and formost our contract is the APIs. Non Python services need to be supported here, too | 16:16 |
| ayoung | dstanek, it was dolphm, that beat that idea into my head. I agree with him. | 16:16 |
| *** ravelar1 has joined #openstack-keystone | 16:17 | |
| *** ravelar has quit IRC | 16:17 | |
| dstanek | ayoung: i don't that what i'm saying excludes anything | 16:18 |
| ayoung | dstanek, if you are going to boot a server from Rust code, you need to know the URL you are calling. | 16:19 |
| ayoung | Should you need to know "that maps to compute:create_server too? | 16:19 |
| ayoung | If so, how do we map that, or map it backwards? I need to doe compute:create_server so what URL do I need to call? | 16:19 |
| ayoung | I want to make the hyperlink the definitive thing, and automate determining the connection between that and the roles required to perform it | 16:20 |
| *** henrynash has joined #openstack-keystone | 16:20 | |
| *** ChanServ sets mode: +v henrynash | 16:20 | |
| openstackgerrit | Samuel Pilla proposed openstack/keystone: Add password expiration queries for PCI-DSS https://review.openstack.org/403898 | 16:21 |
| dstanek | ayoung: because we are not a RESTful system then there will need to be mapping somewhere. i'd honestly like to push that into client writers than policy writers and users. | 16:22 |
| *** henrynash has quit IRC | 16:23 | |
| ayoung | dstanek, please expound on that | 16:23 |
| dstanek | you only really need to know the URL currently if you write your own client or use curl right? | 16:23 |
| dstanek | i've used both python and java clients to create vms and i have no idea what URLs were actually used. but i do know that i created them. and i suspect i know how to modify policy for them (but you guys did mention nova dragons) | 16:25 |
| openstackgerrit | Samuel Pilla proposed openstack/keystone: API Documentation for user password expires https://review.openstack.org/405574 | 16:26 |
| dstanek | i may say 'nova.reboot("123")' or 'nova->reboot_vm("123")' and in my mind that maps to an operation i am doing | 16:26 |
| dstanek | now if i using curl then i've probably already lost (or i'm probably developing/debuggin openstack) | 16:27 |
| *** adrian_otto has joined #openstack-keystone | 16:27 | |
| ayoung | dstanek, your mind may map that, but there is, as of now, no way of automatically correctly mapping that to policy | 16:27 |
| dstanek | as an admin of a domain i was to give you the right to start and reboot VMs. i can't imagine horizon will show this as a list of URLs | 16:28 |
| ayoung | However, if it were based on the URL, both the Java and Python apis would have a means to do so | 16:28 |
| ayoung | dstanek, the more information an API provides, the more the UX team can do with it. | 16:29 |
| dstanek | ayoung: clients now already know the mapping (generally speaking) they named the method reboot because it reboots | 16:29 |
| ayoung | An example from the FreeIPA UI: | 16:29 |
| ayoung | IPA, based on LDAP, can query down to the individual property level is a user can read write (and more) | 16:29 |
| ayoung | based on that, the UI can chose to show a given field as read only, writable, or not bother to show it | 16:30 |
| ayoung | You don't need to show the field name, just the expected permissions on it | 16:30 |
| ayoung | So, Horizon would say "here is a complex page, with multiple panels. Let me query what a user can do for Op1, Op2, Op2 and tailor that page to them | 16:31 |
| ayoung | They would not give the user a list of URLs, they would query based on the state of the system. Not something we can do today | 16:31 |
| dstanek | ayoung: what would the query on? | 16:31 |
| edmondsw | dstanek horizon is a client. So it's just fine that it needs to know the URLs. Doesn't mean it will show the URLs to users in its buttons | 16:32 |
| ayoung | dstanek, to start, they could query a list API, see if that goes through | 16:32 |
| ayoung | if it does, they could select an item from that list and query on that | 16:32 |
| *** kragniz has quit IRC | 16:32 | |
| *** henrynash has joined #openstack-keystone | 16:33 | |
| *** ChanServ sets mode: +v henrynash | 16:33 | |
| dstanek | so say they are on page for a VM they have to query on a bunch of URLs that are somewhat related to VMs? | 16:33 |
| *** kragniz has joined #openstack-keystone | 16:33 | |
| dstanek | in my mind this goes back to what i wanted in atlanta. a heirarchy of operations grouped by resource | 16:34 |
| ayoung | dstanek, so, they *could* but in all likelhood, they would fetch and cache the information instead | 16:34 |
| edmondsw | dstanek no, they would query the api_roles API to see what they should/shouldn't show | 16:34 |
| dstanek | that would be all in one document and the document could be dynamic based on the user | 16:34 |
| ayoung | edmondsw, ++ | 16:34 |
| ayoung | dstanek, ... actually, this would be pretty much that, or at least enough information to generate it | 16:35 |
| *** henrynash has quit IRC | 16:35 | |
| ayoung | kind of like a permissions based json_home | 16:35 |
| edmondsw | api_roles response is your document, just tied to role instead of to user. The client will know the role of the user, so it amounts to the same thing | 16:35 |
| ayoung | but, the thing is that we are trying to solve this for more than just the known openstack services | 16:35 |
| ayoung | there are an ever growing set of them that use Keystone now | 16:35 |
| dstanek | so each client maintains their own list of URLs groups by resource under this scheme? | 16:36 |
| ayoung | We could generate the one for the user, though, from that data. | 16:36 |
| ayoung | dstanek, the "SERVICE" is the set of resources grouped together here | 16:36 |
| openstackgerrit | Richard Avelar proposed openstack/keystone: Add doctor tests on security_compliance and rename https://review.openstack.org/408743 | 16:36 |
| ayoung | and, I'd like to point out that we could totally abuse that term | 16:36 |
| edmondsw | dstanek ? | 16:36 |
| dstanek | ayoung: but i want to know what can be done to this VM. how do i do that? | 16:37 |
| ayoung | and have a different "service" value for different endpoints of the same service... | 16:37 |
| edmondsw | dstanek to know what can be done to VMs (it's based on resource type, not instance) you query the api_roles API and parse out the information for that resource type | 16:37 |
| edmondsw | it will tell you which roles can call those APIs | 16:38 |
| edmondsw | you already know which APIs you support calling and what buttons you've mapped those to | 16:38 |
| ayoung | dstanek, I think you are getting at the fact that a VM is a complex object with multiple operations on it, and that they might be buried inside the POST operations for a simple WEB API. I can't claim that I am solving that here | 16:38 |
| ayoung | The wide variety in how different APIs are implemented make it impossible to retro fit a tool to work with all of them. I am trying to get us to the start of a process that gives us a way to grow these rules | 16:39 |
| ayoung | some might end up requiring service engineers to come up with new APIs for exisint resources | 16:39 |
| ayoung | and someone might end up demanding that we look inside the POST/PUT/PATCH payloads | 16:39 |
| ayoung | incremental | 16:39 |
| ayoung | I am trying to avoid doing that prematurely | 16:40 |
| ayoung | this is not going to be the end all be all, just a reasonable progression based on the current state, and the limitiations and requests we've had in the past several years | 16:40 |
| openstackgerrit | Samuel Pilla proposed openstack/keystone: API Documentation for user password expires https://review.openstack.org/405574 | 16:40 |
| dstanek | ayoung: ok, i want to capture some of this... | 16:42 |
| ayoung | I think this approach will drive us toward more restful solutions | 16:42 |
| ayoung | dstanek, awesome | 16:42 |
| dstanek | ayoung: if i am writing a client do i need to care about policy...should i? | 16:42 |
| ayoung | dstanek, edmondsw thanks so much. These are the conversations I've wanted to have around this topic. I did not want to be forcing something on other people, but rather helpoing refine and guide based on mahny people's experiences | 16:43 |
| ayoung | dstanek, ideally, no | 16:43 |
| ayoung | dstanek, I see policy as a cross cutting concern, specifically, the RBAC side of it | 16:43 |
| ayoung | for delegation, it is a case of saying, if User 1 can do this, they need to be able to set up automation to do it on their behalf that can do only that | 16:43 |
| dstanek | ayoung: i'm going to argue out every point until we get it right :-P | 16:44 |
| ayoung | "that" in this case is the operation, whatever it is | 16:44 |
| dstanek | ayoung: i'm assuming as a user of a client you only care about policy when you get a message saying you don't have permission | 16:44 |
| ayoung | dstanek, how about instead of "until we get it right" we aim for "until we get something practical" | 16:44 |
| dstanek | ayoung: fair enough | 16:44 |
| dstanek | ayoung: as a cloud admin i care about policy so that i can protect some operations | 16:45 |
| ayoung | dstanek, I would say I also care about it when I want to have something else do it on my behalf | 16:45 |
| ayoung | delegation is a huge driving factor here | 16:45 |
| dstanek | and as a user wishing to delegate responsibility i care because i have to know what can be delegated | 16:45 |
| ayoung | dstanek, remember people asking for a "READ ONLY" role? | 16:45 |
| ayoung | dstanek, right | 16:45 |
| dstanek | ayoung: yep, i'm breaking up all the cases | 16:46 |
| ayoung | dstanek, so we have a 2 dimensional system: role is scoped to project. project is the set of resources of a specific type that are all treated the same way | 16:46 |
| ayoung | its imperfect, but it is what we have | 16:46 |
| ayoung | so we can vary the role, or we can vary the project | 16:46 |
| dstanek | ayoung: do we consider horizon a client liek edmondsw said or should it have a deeper knowledge about policy? i think it needs that deep understanding | 16:47 |
| ayoung | this spec is focused on varying only the role. | 16:47 |
| ayoung | it is a cliejnt | 16:47 |
| ayoung | client | 16:47 |
| ayoung | dstanek, ideally, a single openstack deployment would have one horizon instance for each X....where X is some granularity of group of users | 16:47 |
| ayoung | I could see a case where, with Federation, each IdP gets its own Horizon | 16:47 |
| ayoung | and its own AUTH_URL | 16:47 |
| *** browne has joined #openstack-keystone | 16:47 | |
| ayoung | still talking to the same keystone database | 16:48 |
| dstanek | ayoung: i'm not really focused on the spec directly right now. i'm trying to discover what the end state of policy should be (within the constraints of openstack, of course) so that i can properly judge all the specs and marching in that direction | 16:48 |
| edmondsw | some clients will need less understanding of what's allowed than horizon, but I would still call horizon a client | 16:48 |
| *** Ephur has joined #openstack-keystone | 16:48 | |
| edmondsw | dstanek ++ | 16:48 |
| *** clenimar has joined #openstack-keystone | 16:49 | |
| dstanek | edmondsw: yes, i agree that technically it's a client, but in our context i think we need to treat it as special | 16:49 |
| edmondsw | dstanek yes, it (and other UI clients) are probably the only things that will call this api_roles API besides the validation logic in middleware | 16:50 |
| *** udesale has quit IRC | 16:54 | |
| *** tqtran has joined #openstack-keystone | 16:55 | |
| ayoung | edmondsw, I can see Heat using it, and Mistral | 16:55 |
| ayoung | Heat often has to create trusts for users. This would allow Heat to create scoped down trusts based on the workflows the user is setting up | 16:56 |
| edmondsw | cool | 16:59 |
| *** rcernin has joined #openstack-keystone | 16:59 | |
| dstanek | ayoung: do you think the openstack community would be open to using links and relations more to avoid hardcoding URLs? | 17:00 |
| ayoung | dstanek, Heh. That is a good question. I think you will not get a consensus, but the majority of people would prefer it | 17:01 |
| ayoung | We would need to be able to provide a means to use those links | 17:01 |
| ayoung | and I think that "meaning" is the hardest part of all | 17:01 |
| ayoung | there is *always* some A-priori knowledge you have. | 17:02 |
| ayoung | The goal is to minimize the amount, and to maximize discoverability | 17:02 |
| *** asettle has quit IRC | 17:02 | |
| ayoung | that is why I don't like the API/JSON-Home emphasis, but I understand why people want it | 17:03 |
| *** asettle has joined #openstack-keystone | 17:03 | |
| dstanek | ayoung: yep. part of the HATEOAS constraint to to spend time documenting the doctype and relationships | 17:03 |
| *** pcaruana has quit IRC | 17:03 | |
| dstanek | instead of keystone documenting '/v2/users' we should be documenting that as a list-users relation or something liek that | 17:04 |
| ayoung | users is a doc type? | 17:04 |
| *** asettle__ has joined #openstack-keystone | 17:05 | |
| ayoung | dstanek, multiple APIs get to the same doc-types? | 17:05 |
| dstanek | no, our doctype is based on JSON, but isn't documented on consistent. /v3/users is a link that appears on the main versioned resource? | 17:06 |
| dstanek | so, as a client i know 3 things to get a list of users: the entrypoint, the version i was and the relation i need | 17:06 |
| dstanek | i GET / and find the version i want from JSON-Home. from there i get that resouce and look for a relation. | 17:07 |
| *** asettle has quit IRC | 17:07 | |
| dstanek | it's really just orchestration of a standard HTTP client | 17:07 |
| *** Zer0Byte__ has joined #openstack-keystone | 17:09 | |
| *** Zer0Byte__ has quit IRC | 17:09 | |
| *** asettle__ has quit IRC | 17:09 | |
| ayoung | dstanek, should the GET /v3 response from keystone have a list of resources in it? | 17:10 |
| ayoung | actually, not there, it would be later... | 17:10 |
| *** udesale has joined #openstack-keystone | 17:10 | |
| ayoung | OK, so we start with an AUTH_URL, which really should tell the user where to start | 17:11 |
| ayoung | lets assume a Federation use case, as AI think that will be the norm | 17:11 |
| ayoung | now, lets assume a Keystone server that supports at least 2 IdPs | 17:11 |
| ayoung | so the AUTH_URL ideallyt would be https://hostname:port/v3/OS_FEDERATION/idp/<idpID> | 17:12 |
| ayoung | I know our current scheme does not support this | 17:12 |
| ayoung | but stick with me | 17:12 |
| dstanek | ayoung: right | 17:12 |
| ayoung | lets assume it does, and now the user wants ot authenticate | 17:12 |
| ayoung | from that URL, they should get a list of protocols | 17:12 |
| ayoung | and then they can chose which to use for this session | 17:13 |
| ayoung | so they go to https://hostname:port/v3/OS_FEDERATION/idp/redhat/protocol/x509 and get an unscoped token | 17:13 |
| ayoung | that token response should have mini service catalog in it | 17:13 |
| ayoung | jamielennox suggested that a long time back. That service catalog should have only the identity endpoint with enough information about the things you can do with an unscoped toke | 17:14 |
| ayoung | token | 17:14 |
| ayoung | list projects for user is the big one | 17:14 |
| *** Marcellin__ has joined #openstack-keystone | 17:14 | |
| ayoung | but change password, and other keystone things that are not necessarily scoped, too | 17:14 |
| ayoung | now, the user picks a project and rescopes: uses their unscoped token to get a scoped one for that project | 17:15 |
| ayoung | that token does not necessarily have to have every role on it. | 17:15 |
| ayoung | I would argue that, if you are an adminisrtator, it should have "Member" on it | 17:15 |
| ayoung | and to convert an unscoped token to a scoped token with admin on it, you have to explicitly request it | 17:16 |
| ayoung | but back to discoverability | 17:16 |
| dstanek | so far you are descibing something very similar to what i'd love to have | 17:16 |
| ayoung | once I have that scoped token, I should get a list of services from the service catalog | 17:16 |
| ayoung | now, I pick the Keystone one, and I query it | 17:16 |
| *** GB21 has quit IRC | 17:16 | |
| ayoung | and it tells me the resources support by Keystone | 17:16 |
| ayoung | the service value here is kindof the doctype | 17:17 |
| ayoung | it is a shorthand for the description doc for the identity service | 17:17 |
| ayoung | now, we do it this way to streamline common cases, but it could also flow like this: | 17:18 |
| ayoung | when I use the unscoped token to get a scoped token, all I get back is a URL that says "here is the service catalog" | 17:18 |
| ayoung | I use that URL to fetch the service catalog, and from there I get the URL to the identity service | 17:19 |
| ayoung | from the URL for the identity service, I get a set of resources that the identity service can manage: this list should be filtered by my role assignment on that project | 17:20 |
| ayoung | only show me resources that I can, in some way, effect | 17:20 |
| ayoung | so that doc would have /project/<id> in it, as well as a link to list the users with roles on that project. | 17:21 |
| dstanek | yep, like in a webpage that shows a field as readonly as opposed to it being in a writable text box | 17:21 |
| ayoung | dstanek, or a dynimic DIV that renders only if it has data, but yes | 17:21 |
| dstanek | exactly | 17:22 |
| knikolla | the discoverability aspect of this looks really really cool. | 17:22 |
| ayoung | dstanek, this is why I wanted keystone to render in HTML. It makes all this so obvious | 17:22 |
| dstanek | the tradeoff with this approach is the number of requests needed against the ease at which clients can be generically implemented | 17:23 |
| ayoung | you hit your keystone with a web browser, you get a token, you click around, and there is a link to everything you want to do | 17:23 |
| dstanek | the number of requests can be mitigated with caching, but some of the dynamicness might have to go away | 17:23 |
| *** nicolasbock has quit IRC | 17:23 | |
| *** nicolasbock has joined #openstack-keystone | 17:23 | |
| ayoung | for a given resource, there should be a link to a page that gives you a form in HTML | 17:23 |
| ayoung | dstanek, that is why we have cache headers | 17:23 |
| ayoung | the resource URLs themselves would not change much | 17:24 |
| ayoung | if a user lost a role assignemnt, the URL that points to that role assignment by id would 404 | 17:24 |
| dstanek | ayoung: no, but they may vary based on user/role/whatever if we are not careful | 17:24 |
| ayoung | dstanek, we have a lot of objects that are named by uuids | 17:24 |
| dstanek | all that is part of the consideration for designing an API that is not solely URL based | 17:24 |
| ayoung | the /user/role might also return it | 17:25 |
| ayoung | but it would have a self link toe /v3/role_assignment/<id> | 17:25 |
| dstanek | why hardcode /user/1234 when /user?id=1234 would work too? | 17:25 |
| ayoung | dstanek, I don;t care | 17:25 |
| ayoung | so long as there is a canonical way to define it, it works for me | 17:26 |
| dstanek | ayoung: exactly! | 17:26 |
| dstanek | you don't even need to define it, instead you define a user relation | 17:26 |
| dstanek | first you define all the relations so that a client developer will know what they mean | 17:27 |
| *** chlong has quit IRC | 17:27 | |
| dstanek | then you defined a doctype so that clients will know how/where to find stuff | 17:27 |
| ayoung | dstanek, right, so I know that to change a user I need to call PATCH <USERURL>. I can try it and get back a 401 and see that I don't have permission. | 17:28 |
| dstanek | for example, html is the doctype and you know what to do with an input and a button. google.com defines the relations | 17:28 |
| ayoung | But lets say we are talking...a network in Neutron | 17:28 |
| ayoung | I don't want to change it, but I have a service that does | 17:29 |
| ayoung | I know I could change it by calling PATCH <networkURL> | 17:29 |
| ayoung | but I don't want to call it | 17:29 |
| ayoung | I want to let that service call it at some point in the future | 17:29 |
| ayoung | I want to create a delegation that says "you can do this, and only this" | 17:29 |
| dstanek | you would deletgate networking:update-network | 17:31 |
| ayoung | dstanek, how would you know that? | 17:32 |
| dstanek | maybe even 'networking:update-network:id=xyz' | 17:32 |
| knikolla | would keystone or neutron maintain that? | 17:32 |
| ayoung | so I should be able to query PATCH <URL> and get back 'networking:update-network:id=xyz' | 17:32 |
| dstanek | you know what the relation update-network mean | 17:32 |
| dstanek | s | 17:32 |
| ayoung | dstanek, that is A-Priori knowlege, what we were trying to avoid above | 17:32 |
| dstanek | ayoung: you have to have entrypoint and an understanding of relations a-priori | 17:33 |
| ayoung | dstanek, instead, on the GET <URL> you should get back a link that has 'networking:update-network:id=xyz' in it | 17:33 |
| ayoung | but...thinmk what that means: we are requiring a specific value on every GET operation throughout openstack | 17:34 |
| ayoung | Roles and tokens are already out of band information | 17:34 |
| dstanek | no, so what i'm thinking (and i haven't designed out all of the cases): | 17:34 |
| ayoung | so...I'm compromising here | 17:35 |
| ayoung | go on | 17:35 |
| dstanek | a user is given access to update a particular network via roles or whatever | 17:35 |
| dstanek | that is stored as the allowed relation and the id (this is only one way) | 17:35 |
| dstanek | when something goes to use that delegation they know they want to update a network. they crawl through the resources to find that network. more concretely then would | 17:36 |
| *** chrisplo has quit IRC | 17:37 | |
| dstanek | GET / on neutron, find the search of query for networks, get the correct one and get the method/url for updating that network | 17:37 |
| dstanek | that assumes that all services are RESTful though, which will probably not happen in my lifetime | 17:38 |
| ayoung | dstanek, so at a minimum, I want an API/Mechanism that lets me say "OK, I have this URL here, what do I need to do to execute it?" | 17:39 |
| dstanek | what's the case where you as a user actually have the url? | 17:40 |
| openstackgerrit | Samuel Pilla proposed openstack/keystone: API Documentation for user password expires https://review.openstack.org/405574 | 17:41 |
| *** henrynash has joined #openstack-keystone | 17:45 | |
| *** ChanServ sets mode: +v henrynash | 17:45 | |
| *** chris_hultin is now known as chris_hultin|AWA | 17:47 | |
| *** Zer0Byte__ has joined #openstack-keystone | 17:50 | |
| *** rcernin has quit IRC | 17:52 | |
| *** rcernin has joined #openstack-keystone | 17:52 | |
| *** chlong has joined #openstack-keystone | 18:01 | |
| *** GB21 has joined #openstack-keystone | 18:05 | |
| *** jdennis1 has joined #openstack-keystone | 18:11 | |
| *** jdennis has quit IRC | 18:12 | |
| openstackgerrit | Samuel de Medeiros Queiroz proposed openstack/keystone: API Documentation for user password expires https://review.openstack.org/405574 | 18:12 |
| openstackgerrit | Richard Avelar proposed openstack/keystone: Add checks for doctor credential symptoms https://review.openstack.org/409289 | 18:17 |
| *** rcernin has quit IRC | 18:17 | |
| *** henrynash has quit IRC | 18:20 | |
| *** asettle has joined #openstack-keystone | 18:24 | |
| *** asettle has quit IRC | 18:26 | |
| *** asettle has joined #openstack-keystone | 18:26 | |
| openstackgerrit | Richard Avelar proposed openstack/keystone: Add doctor checks for ldap symptoms https://review.openstack.org/409292 | 18:30 |
| *** harlowja has joined #openstack-keystone | 18:32 | |
| *** harlowja_ has joined #openstack-keystone | 18:34 | |
| *** harlowja has quit IRC | 18:35 | |
| *** ravelar1 has quit IRC | 18:35 | |
| *** GB21 has quit IRC | 18:36 | |
| openstackgerrit | Samuel de Medeiros Queiroz proposed openstack/keystone: Add doctor tests on security_compliance and rename https://review.openstack.org/408743 | 18:36 |
| *** haplo37_ has quit IRC | 18:55 | |
| *** haplo37_ has joined #openstack-keystone | 18:56 | |
| *** haplo37_ has quit IRC | 18:59 | |
| *** haplo37_ has joined #openstack-keystone | 18:59 | |
| *** david-lyle_ is now known as david-lyle | 19:13 | |
| *** asettle has quit IRC | 19:16 | |
| *** asettle has joined #openstack-keystone | 19:16 | |
| stevemar | so many doctor tests :| | 19:18 |
| stevemar | note, i'm not dying ^ i am referring to the keystone-doctor | 19:21 |
| *** asettle has quit IRC | 19:21 | |
| stevemar | some say he is related to dr. doom | 19:21 |
| rodrigods | lol | 19:24 |
| openstackgerrit | Gage Hugo proposed openstack/keystone: Add reason to notifications for PCI-DSS https://review.openstack.org/396752 | 19:24 |
| *** udesale has quit IRC | 19:26 | |
| *** chris_hultin|AWA is now known as chris_hultin | 19:37 | |
| knikolla | stevemar: can we add a doctor test for symptom too many doctor tests? | 19:40 |
| gagehugo | meta doctor tests | 19:43 |
| *** openstack has joined #openstack-keystone | 19:44 | |
| *** Marcellin__ has quit IRC | 19:49 | |
| stevemar | knikolla: :) | 19:51 |
| morgan | knikolla: E_TOO_MANY_TESTS("You've added another test... Sorry but you must now increase your premiums/buy private keystone-health-insurance to accommodate the extra labor needed to test your keystone install. We recommend talking to your local keystone developer for more information." (cc stevemar ) | 20:02 |
| knikolla | morgan: keystone-health-insurance hahaha | 20:05 |
| *** masber has quit IRC | 20:07 | |
| *** masber has joined #openstack-keystone | 20:07 | |
| *** spzala has quit IRC | 20:18 | |
| stevemar | :) | 20:19 |
| *** raildo has quit IRC | 20:30 | |
| dstanek | is ldap on devstack broken? | 20:38 |
| *** rcernin has joined #openstack-keystone | 20:38 | |
| *** rcernin has quit IRC | 20:38 | |
| *** rcernin has joined #openstack-keystone | 20:38 | |
| *** spzala has joined #openstack-keystone | 20:42 | |
| *** spzala has quit IRC | 20:46 | |
| *** spzala has joined #openstack-keystone | 20:56 | |
| *** masuberu has joined #openstack-keystone | 20:58 | |
| *** jamielennox|away is now known as jamielennox | 20:58 | |
| *** masber has quit IRC | 20:59 | |
| rodrigods | dstanek, looks like it is | 21:03 |
| rodrigods | annakoppad was taking a look on it | 21:04 |
| knikolla | rodrigods: are you going to make the project-config patch for the env vars you need in the tests? | 21:06 |
| rodrigods | knikolla, it's on my todo list | 21:07 |
| rodrigods | i also need to add a feature flag for the tests | 21:07 |
| rodrigods | but,... you can go ahead if you have some free time | 21:07 |
| knikolla | rodrigods: i'm afraid to even look at my todo list | 21:07 |
| *** adrian_otto has quit IRC | 21:08 | |
| rodrigods | lol | 21:08 |
| rodrigods | ok | 21:08 |
| rodrigods | i should be able to do that next week | 21:09 |
| *** ravelar1 has joined #openstack-keystone | 21:11 | |
| dstanek | rodrigods: hmmm...that sucks. i really want to test | 21:12 |
| ayoung | edmondsw, I rememberwhy I wanted the is_admin_project check in RBAC | 21:25 |
| edmondsw | ayoung why? | 21:25 |
| ayoung | it was to give power to the admins to decide whether it should be a global admin check or not | 21:25 |
| edmondsw | ? | 21:26 |
| ayoung | since it is not yet definied in all the policy files, it gives a way to get it into the field, too | 21:26 |
| ayoung | but that is just me being lazy | 21:26 |
| edmondsw | and they don't have that in policy because... | 21:26 |
| ayoung | there might be an API that is currently admin only | 21:26 |
| ayoung | cuz I have not got all the reviews through to do it... | 21:26 |
| edmondsw | I would pull it out either way, and make it a separate spec where we can debate the merits | 21:27 |
| ayoung | edmondsw, deal | 21:27 |
| *** chlong has quit IRC | 21:29 | |
| *** edtubill has quit IRC | 21:34 | |
| *** ravelar1 has quit IRC | 21:37 | |
| *** adrian_otto has joined #openstack-keystone | 21:37 | |
| morgan | edmondsw: oh hi! | 21:40 |
| morgan | edmondsw: that is a name i've not seen in a while | 21:40 |
| edmondsw | morgan hey there | 21:40 |
| edmondsw | you caught me... ;) | 21:40 |
| morgan | oh adriant isn't here | 21:40 |
| morgan | edmondsw: yah. | 21:41 |
| morgan | edmondsw: you should come around more often. we're friendly (still), I swear | 21:41 |
| edmondsw | ha! | 21:41 |
| edmondsw | yeah, it's all a matter of time... I will be at the PTG though | 21:41 |
| morgan | i've booked my ticket | 21:41 |
| edmondsw | and hopefully around more | 21:41 |
| morgan | i may be there, i may not | 21:41 |
| edmondsw | well, I hope you will | 21:42 |
| morgan | but it is quite possible you can find me there | 21:42 |
| * morgan skipped barcelona and the keystone midcycle | 21:42 | |
| * edmondsw did as well | 21:42 | |
| morgan | dstanek: ok | 21:42 |
| morgan | going to start on the MFA stuff | 21:42 |
| morgan | dstanek: what do you think, an additional column on USER | 21:42 |
| morgan | or a new table with a user FK | 21:43 |
| morgan | ? | 21:43 |
| morgan | cc ayoung, bknudson, stevemar, and the rest of the cores [if you care] | 21:43 |
| * morgan is leaning towards a separate table | 21:43 | |
| morgan | with a FK. | 21:43 |
| morgan | not a "FK" in sql sense, i guess, just a "logical" fk so we could support LDAP users with this API since Auth is semi-independant of LDAP | 21:44 |
| morgan | (etc) | 21:44 |
| *** ravelar1 has joined #openstack-keystone | 21:45 | |
| morgan | zzzeek: does Alembic allow for multiple migration repos for a single DB? | 21:47 |
| morgan | zzzeek: because... i remember it didn't before... | 21:47 |
| zzzeek | morgan: yes | 21:47 |
| morgan | zzzeek: cool. | 21:47 |
| morgan | stevemar: we need to do the collapse for mitaka migrations. | 21:48 |
| morgan | stevemar: to* | 21:48 |
| morgan | not for | 21:48 |
| * morgan is a bit sad the expand/contract repos aren't alembic | 21:48 | |
| morgan | that could have been a natural progression from SQL-A | 21:48 |
| *** edmondsw has quit IRC | 21:48 | |
| morgan | SQL-A-Migrate | 21:49 |
| zzzeek | morgan: neutron does all of this | 21:50 |
| *** dave-mccowan has quit IRC | 21:50 | |
| zzzeek | per-release expand/contract directories | 21:50 |
| morgan | zzzeek: yeah, i figured. just keystone had an opportunity to move to alembic :) | 21:50 |
| morgan | with the expand/contract directory addtions | 21:50 |
| morgan | but we didn't. | 21:50 |
| morgan | *oh well* | 21:50 |
| * morgan does this migration with SQL-A-Migrate | 21:50 | |
| *** edmondsw has joined #openstack-keystone | 21:52 | |
| *** edmondsw has quit IRC | 21:52 | |
| openstackgerrit | Samuel Pilla proposed openstack/keystone: Add password expiration queries for PCI-DSS https://review.openstack.org/403898 | 21:57 |
| *** spzala has quit IRC | 21:57 | |
| openstackgerrit | Samuel Pilla proposed openstack/keystone: Add password expiration queries for PCI-DSS https://review.openstack.org/403898 | 21:57 |
| *** chlong has joined #openstack-keystone | 22:02 | |
| *** spzala has joined #openstack-keystone | 22:03 | |
| openstackgerrit | Samuel Pilla proposed openstack/keystone: Add password expiration queries for PCI-DSS https://review.openstack.org/403898 | 22:03 |
| *** rcernin has quit IRC | 22:04 | |
| *** jamielennox is now known as jamielennox|away | 22:04 | |
| ayoung | morgan, needs to be outside of LDAP and Federation for certain | 22:05 |
| ayoung | beyond that...no real care here | 22:05 |
| openstackgerrit | Ron De Rose proposed openstack/keystone: Require domain_id when registering Identity Providers https://review.openstack.org/399684 | 22:06 |
| openstackgerrit | ayoung proposed openstack/keystone-specs: Role Check from Middleware https://review.openstack.org/391624 | 22:06 |
| *** spzala has quit IRC | 22:07 | |
| morgan | ayoung: done, making it a separate table | 22:08 |
| openstackgerrit | Ron De Rose proposed openstack/keystone: Require domain_id when registering Identity Providers https://review.openstack.org/399684 | 22:10 |
| *** jamielennox|away is now known as jamielennox | 22:11 | |
| *** ravelar1 has quit IRC | 22:17 | |
| *** asettle has joined #openstack-keystone | 22:19 | |
| openstackgerrit | Ron De Rose proposed openstack/keystone: Require domain_id when registering Identity Providers https://review.openstack.org/399684 | 22:23 |
| *** asettle has quit IRC | 22:24 | |
| stevemar | morgan: hmm, why do we *need* to collapse the migrations? | 22:31 |
| openstackgerrit | Ron De Rose proposed openstack/keystone: Require domain_id when registering Identity Providers https://review.openstack.org/399684 | 22:34 |
| openstackgerrit | Ron De Rose proposed openstack/keystone: Require domain_id when registering Identity Providers https://review.openstack.org/399684 | 22:38 |
| *** browne has quit IRC | 22:44 | |
| rderose | ayoung: ^ modified this patch to enforce 1:1 (idp:domain) | 22:44 |
| *** arunkant has quit IRC | 22:44 | |
| *** tqtran has quit IRC | 22:44 | |
| *** pnavarro has quit IRC | 22:46 | |
| *** arunkant has joined #openstack-keystone | 22:47 | |
| *** tqtran has joined #openstack-keystone | 22:47 | |
| *** browne has joined #openstack-keystone | 22:47 | |
| stevemar | rderose: ++ | 22:50 |
| stevemar | rodrigods: you don't need a bug for this! :P https://bugs.launchpad.net/keystone/+bug/1648886 | 22:50 |
| openstack | Launchpad bug 1648886 in OpenStack Identity (keystone) "OpenStack Identity API doc pointing to specs" [Undecided,New] | 22:50 |
| ayoung | rderose, will that work? | 22:52 |
| ayoung | stevemar, never hurts to have a bug recorded before you fix something, lets you forget about it and soemone else can fix | 22:52 |
| ayoung | morgan, I read qthat as SQL-A-Migraine | 22:53 |
| *** chris_hultin is now known as chris_hultin|AWA | 22:55 | |
| browne | federation quesetion: does keystone keep some sort of state when doing the SAML exchange? | 23:04 |
| browne | i notice in my setup, whcih has two keystones behind a haproxy talking with a 3rd party IDP | 23:04 |
| browne | i get a infitite loop where theres a redirect to the IDP, then back to the other keystone, then another redirect back to IDP, etc, etc | 23:05 |
| *** r1chardj0n3s is now known as r1chardj0n3s_afk | 23:05 | |
| browne | i'm using mellon, and made sure the key, cert, and xml are the same on each keystone | 23:05 |
| ayoung | browne, something is misconfigured | 23:09 |
| ayoung | browne, that sounds like a Mellon setup problem, though, not keystone at all. Hasn;t gotten to the keystone layer I think | 23:10 |
| stevemar | browne: oh there was something about that... | 23:10 |
| stevemar | ahh | 23:10 |
| browne | ayoung: yeah, maybe its mellon specific, still not sure why | 23:11 |
| browne | my haproxy is configured to load balance round-robin, so the request doesn't go back to the same keystone | 23:11 |
| ayoung | browne, fpaste your httpd/conf.d/ config file for the mellon part please | 23:11 |
| browne | sure | 23:11 |
| browne | http://paste.openstack.org/show/591990/ | 23:12 |
| browne | this is Mitaka, btw | 23:13 |
| browne | and that file in the paste is ansible(ized) | 23:13 |
| *** ravelar1 has joined #openstack-keystone | 23:13 | |
| browne | i'm new to federation, but believe i have it mostly working | 23:15 |
| stevemar | browne: uh, this is so... i remember marek sending me an email about this | 23:15 |
| ayoung | browne, {{ ansible_eth0.ipv4.address }} should probably be a hostname | 23:16 |
| browne | if i shutdown one of the apaches(keystone), then auth works | 23:16 |
| ayoung | you should be using TLS | 23:16 |
| browne | ayoung: yeah, there are no hostnames. private IPs only on this mgmt network | 23:16 |
| ayoung | browne, does that match what you tell the outside world? | 23:17 |
| browne | TLS is provided using SSL termination at haproxy | 23:17 |
| ayoung | a lot of redirect problems are due to the names not matching | 23:17 |
| ayoung | are you trying to do websso? | 23:17 |
| browne | yes | 23:17 |
| ayoung | browne, does it get as far as letting you log in to the IdP? | 23:18 |
| browne | yes | 23:18 |
| browne | then i think the saml token goes to the other keystone, and it begins again | 23:18 |
| ayoung | so once you log in, it kicks you back to the same URL that you origianlly hit on Keystone, which does not accept the SAML assertion and thus kicks you back to the IdP.... | 23:19 |
| browne | until the IdP quits telling me there were too many requests | 23:19 |
| browne | ayoung: yes | 23:19 |
| ayoung | I think you need to make the two keystone servers have the same hostname | 23:19 |
| ayoung | <VirtualHost {{ ansible_eth0.ipv4.address }}:5000> should be <VirtualHost {{ keystone_hostname }}:5000> | 23:20 |
| browne | so what part matters for that? mellon? | 23:20 |
| browne | for mellon i generated the key, cert, xml for the public_hostname of haproxy | 23:20 |
| ayoung | browne, mellon is going to post a request to the idp with its identity. call that keystone1. IdP will grant an assertion valid for keystone1. HA sensds the response to keystone2. | 23:21 |
| browne | ayoung: i don't have any hostnames on this controller. only IPs for keystone, apache, horizon, etc | 23:21 |
| ayoung | Keystone 2 looks at assertion and says "this is not for me" | 23:21 |
| ayoung | browne, give it one and see if it works | 23:21 |
| *** ravelar1 has quit IRC | 23:21 | |
| *** agrebennikov_ has quit IRC | 23:21 | |
| ayoung | its a virtual host directive, so it has to map to the public IP | 23:21 |
| browne | unfortunately its not possible in our setup | 23:22 |
| ayoung | browne, this is SAML. Has nothing to do with Keystone | 23:22 |
| ayoung | an assertion for host1 is not valid for host2 | 23:22 |
| browne | so is there something in SAML that puts the host's IP in it? | 23:23 |
| ayoung | you newed to convince your setup that host1 and host2 are the same thing | 23:23 |
| stevemar | browne: can you DM me an email address? | 23:23 |
| ayoung | browne, yes, it has to | 23:23 |
| stevemar | browne: you are using memcache in your setup right? | 23:23 |
| browne | yes | 23:24 |
| browne | ayoung: ok, i'll do more digging. maybe i can work around this somehow | 23:25 |
| browne | another thing i've seen is weirdness with federation users | 23:25 |
| ayoung | browne, can you pin the HA proxy to a single Keystone server. | 23:25 |
| ayoung | I wouldn't advise it | 23:25 |
| browne | ayoung: yeah, that's the current workaround. | 23:25 |
| browne | sucks for performance | 23:26 |
| ayoung | yeah, so they need the same name somehow. WHat are you using for an AUTH_URL? | 23:26 |
| ayoung | for grins lets say it is | 23:26 |
| ayoung | 18.18.18.54 | 23:26 |
| browne | ayoung: our auth_url is a public hostname at port 5000 | 23:27 |
| browne | on https | 23:27 |
| ayoung | so https://18.18.18.54:5000 | 23:27 |
| stevemar | browne: let me know if the email i sent helps | 23:27 |
| ayoung | ok, so give that a DNS name | 23:27 |
| ayoung | call it openstack.<domain> | 23:27 |
| ayoung | your auth_url becomes https://openstack.example.com:5000 | 23:27 |
| *** chlong has quit IRC | 23:28 | |
| ayoung | the HA proxy setup will forward things to the local, but should still honor the hostname, I think you need to set some directive there | 23:28 |
| ayoung | let me see my POC.... | 23:29 |
| browne | yep, that is how its setup. haproxy has the https://openstack.example.com:5000/ which forwards to one of two keystones | 23:29 |
| browne | currently in round-robin mode, but maybe i just need to change that | 23:30 |
| ayoung | browne, make that your virstualhost | 23:30 |
| ayoung | not the ip address | 23:30 |
| ayoung | <VirtualHost openstack.example.com:5000> | 23:30 |
| browne | that won't work because apache is on a different node that has no public network connectivity | 23:30 |
| ayoung | does not matter | 23:30 |
| ayoung | ha proxy will sent the hostname along with the rewritten IP address | 23:31 |
| ayoung | ServerName https://openstack.ayoung-dell-t1700.test might also be sufficient browne | 23:32 |
| ayoung | or your equivalent | 23:32 |
| ayoung | https://adam.younglogic.com/2016/08/ooo-ha-fed-poc/ | 23:32 |
| browne | i can try, as long as it doesn't attempt to bind on that address | 23:33 |
| *** ravelar1 has joined #openstack-keystone | 23:33 | |
| *** adrian_otto has quit IRC | 23:33 | |
| ayoung | VirtualHost just means that it will take requests for that hostname and map them to the stanza | 23:35 |
| ayoung | for ServerName, I think it is used in outgoing requests, and that is probably the one you need | 23:36 |
| browne | ok, cool, thx i'll give it a shot | 23:38 |
| *** ravelar1 has quit IRC | 23:38 | |
| browne | the other oddity i see is when i have a federated user with the same user name in keystone | 23:38 |
| browne | 2016-12-06 23:40:49.113583 2016-12-06 23:40:49.109 8656 WARNING keystone.common.wsgi [req-e3487ca3-ee4c-4bf8-b6c0-a61825b2ecf4 - - - - -] Authorization failed. Unable to reconcile identity attribute user_id as it has conflicting values 720780bafe4c4c1eb2edae2c4e97d502 and 3728a5d84f854950963a0db196a66aa2 (Disable insecure_debug mode to suppress these details.) (Disable insecure_debug mode to suppress these details.) from 10.1 | 23:38 |
| browne | and they're on different domains, so i don't understand this error | 23:39 |
| ayoung | rderose, ^^ sounds like mapping issues | 23:39 |
| *** ravelar1 has joined #openstack-keystone | 23:41 | |
| *** ravelar1 has quit IRC | 23:46 | |
| *** Ephur has quit IRC | 23:47 | |
| rderose | ayoung browne: hmm... federated unique_id is not being checked against the user.name... | 23:58 |
| rderose | browne: what do you mean, on different domains? do you mean different identity providers? | 23:59 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!