| *** dstanek is now known as dstanek_zzz | 00:01 | |
| *** gyee has quit IRC | 00:01 | |
| *** dgbaley has joined #openstack-keystone | 00:07 | |
| dgbaley | Hey. I'm trying to use the /v3 REST API to create endpoints. It looks like they're created individually, but is there a way to get the legacy_endpoint_id as in /v2.0? Does it matter? | 00:08 |
|---|---|---|
| *** sbfox has quit IRC | 00:08 | |
| *** zhiyan_ is now known as zhiyan | 00:20 | |
| *** leseb has joined #openstack-keystone | 00:27 | |
| *** bknudson has joined #openstack-keystone | 00:29 | |
| *** zhiyan is now known as zhiyan_ | 00:29 | |
| *** leseb has quit IRC | 00:32 | |
| ayoung | gabriel-bezerra, sorry to have been ignoring you, but I've been working on Horizon/Kerberos integration, and it seems to be going swimingly.... | 00:34 |
| ayoung | gabriel-bezerra, and what you are doing with HTTP is going to be a key part of that strategy | 00:34 |
| *** dstanek_zzz is now known as dstanek | 00:41 | |
| *** ozialien has quit IRC | 00:42 | |
| *** zhiyan_ is now known as zhiyan | 00:50 | |
| *** rodrigods has joined #openstack-keystone | 00:54 | |
| dstanek | blah...before my vacation i was hoping to bring the open bug count to 225; i failed | 00:56 |
| *** zhiyan is now known as zhiyan_ | 00:59 | |
| *** praneshp has quit IRC | 01:00 | |
| *** lbragstad has joined #openstack-keystone | 01:01 | |
| *** devlaps has quit IRC | 01:05 | |
| *** rodrigods has quit IRC | 01:06 | |
| *** zhiyan_ is now known as zhiyan | 01:09 | |
| *** ncoghlan has joined #openstack-keystone | 01:11 | |
| *** xianghui has joined #openstack-keystone | 01:12 | |
| *** sbfox has joined #openstack-keystone | 01:13 | |
| morganfainberg | dstanek, solution: delay the vacation! | 01:16 |
| morganfainberg | dstanek, >.> | 01:16 |
| morganfainberg | dstanek, *is not serious, vacations are awesome. someday I might even go on one | 01:17 |
| *** browne has quit IRC | 01:18 | |
| *** ncoghlan is now known as ncoghlan_afk | 01:23 | |
| *** leseb has joined #openstack-keystone | 01:28 | |
| *** sbfox has quit IRC | 01:29 | |
| *** diegows has quit IRC | 01:30 | |
| ayoung | morganfainberg, I'm a Kerberizing fool! | 01:31 |
| *** dstanek is now known as dstanek_zzz | 01:31 | |
| ayoung | http://adam.younglogic.com/2014/05/keystoneclient-s4u2proxy/ | 01:31 |
| ayoung | Now all we need is the patch that lets us Get TGTs of HTTPS and we'll be in Business. | 01:32 |
| *** leseb has quit IRC | 01:33 | |
| *** marcoemorais has quit IRC | 01:33 | |
| *** bobt has quit IRC | 01:33 | |
| morganfainberg | ayoung, tomorrow i'm actually sitting down and seeing how close i can get freeipa to do what i want on ubuntu (it appears to be all packaged and working in 14.04...ish) | 01:34 |
| morganfainberg | ayoung, and starting to get the devstack changes rolled up for it to happen. | 01:34 |
| morganfainberg | ayoung, :) | 01:34 |
| ayoung | Score. | 01:35 |
| ayoung | morganfainberg, shout if you need a hand | 01:35 |
| morganfainberg | ayoung, you know i will | 01:35 |
| morganfainberg | ayoung, i think i have a solid story (mulling it over on how i want to present it) for moving delegation to a base level assignment request - so - non-impersonation-trusts but with the added benefit of limiting roles for evne your access. | 01:38 |
| *** xianghui has quit IRC | 01:38 | |
| morganfainberg | ayoung, bah, didn't describe it well there | 01:38 |
| morganfainberg | ayoung, stupid lack of coffee :) | 01:39 |
| ayoung | No I get it | 01:39 |
| ayoung | "here is my profile for creating a token when I want to create a VM" | 01:39 |
| morganfainberg | ayoung, yep. | 01:39 |
| morganfainberg | ayoung, there ya go | 01:39 |
| ayoung | morganfainberg, the key to the whole thing isgoing to be the audit work | 01:39 |
| ayoung | 1. move audit so that it is triggered from policy | 01:39 |
| morganfainberg | ayoung, yep. which is why i'm still mulling over the details on how to get from here to there. | 01:40 |
| ayoung | 2. use that to determine what actually gets executed when you performa a workflow | 01:40 |
| ayoung | OK...here are some of them | 01:40 |
| ayoung | morganfainberg, lets assume we start with the split of middleware from client | 01:40 |
| morganfainberg | but i figured you'd be interested. | 01:40 |
| morganfainberg | ayoung, that i assumed as much | 01:40 |
| ayoung | we move gordon's middleware for audit into keystonemiddleware | 01:40 |
| ayoung | that is two middleware components | 01:41 |
| ayoung | then, clean up auth token such that it does not enforce the 403 if no token, but lets a policy do its job | 01:41 |
| ayoung | move the current keystone policy enforcement into keystonemiddleware: fully ack that it is not middleware | 01:42 |
| ayoung | but it is server side code | 01:42 |
| morganfainberg | ayoung, huge ++ on that cleanup (403) | 01:42 |
| ayoung | and let the other projects use our decorators, flatten code, etc, to standardize policy enforcement | 01:42 |
| ayoung | then, with audit on, we gather data: here is what you need to delegate in order to perform standard workloads | 01:43 |
| ayoung | endpoint binding + specific delegation and short lived tokens....and we are that much more secure | 01:43 |
| ayoung | I might have skippe a step there near the end | 01:43 |
| morganfainberg | ayoung, ++ | 01:44 |
| morganfainberg | ayoung, need to poke nkinder about the session token spec - i'd like to get the spec for it up for review so we can start moving the peices into place (yes i know horizon needs to be involved too) | 01:45 |
| ayoung | Heh, that is my job. Session token is my baby, he wants just the unscoped to scoped only...but he can't ha that without sessions | 01:46 |
| morganfainberg | ayoung, ah wasn't sure who was going to do the specing on those | 01:47 |
| morganfainberg | ayoung, do you see pure unscoped as a separate spec? | 01:47 |
| morganfainberg | ayoung, with session being dependant, or just pure unscope as a work item | 01:48 |
| ayoung | I see session encompassing both | 01:48 |
| morganfainberg | ayoung, cool | 01:48 |
| morganfainberg | does 'recheck no bug' no longer work? | 01:51 |
| ayoung | nope | 01:53 |
| ayoung | you need a bug | 01:53 |
| ayoung | Choose Bug 1 | 01:53 |
| morganfainberg | nah it works | 01:53 |
| morganfainberg | reverify no bug doesn't work | 01:53 |
| morganfainberg | ayoung, https://review.openstack.org/#/c/91145/ | 01:54 |
| ayoung | https://bugs.launchpad.net/ubuntu/+bug/1 | 01:54 |
| morganfainberg | just can;t have other cruft in the comment | 01:54 |
| uvirtbot | ayoung: Error: Could not parse data returned by Launchpad: HTTP Error 503: Service Unavailable | 01:54 |
| morganfainberg | *snerk* | 01:54 |
| *** xianghui has joined #openstack-keystone | 01:55 | |
| ayoung | Recheck Bug 1 | 01:55 |
| morganfainberg | we now have configurable hashes and compressed token support in cms (though i don't think we can make the compressed provider default until everyone has gone to minimum of 0.9.0 of ksc | 01:55 |
| ayoung | ++ | 01:55 |
| ayoung | lets just make it possible in Juno, and default in Kilo | 01:56 |
| morganfainberg | thats fine. | 01:56 |
| morganfainberg | still need 100% support for apache services gate | 01:56 |
| morganfainberg | ok i need to bail. OS meetup. | 01:57 |
| morganfainberg | time to go be social or something | 01:58 |
| morganfainberg | :) | 01:58 |
| morganfainberg | be back in a while. | 01:58 |
| morganfainberg | oh quick review: https://review.openstack.org/#/c/96647/ | 01:58 |
| *** lbragstad has quit IRC | 02:08 | |
| *** xianghui has quit IRC | 02:12 | |
| *** ozialien has joined #openstack-keystone | 02:12 | |
| *** ncoghlan_afk is now known as ncoghlan | 02:13 | |
| ayoung | morganfainberg, https://review.openstack.org/#/c/96648/ | 02:16 |
| *** sbfox has joined #openstack-keystone | 02:18 | |
| *** dstanek_zzz is now known as dstanek | 02:22 | |
| *** sbfox has quit IRC | 02:24 | |
| *** xianghui has joined #openstack-keystone | 02:26 | |
| *** dims has quit IRC | 02:28 | |
| *** leseb has joined #openstack-keystone | 02:29 | |
| *** dstanek is now known as dstanek_zzz | 02:32 | |
| *** leseb has quit IRC | 02:33 | |
| *** dstanek_zzz is now known as dstanek | 02:34 | |
| *** harlowja_ is now known as harlowja_away | 02:41 | |
| *** dstanek is now known as dstanek_zzz | 02:44 | |
| *** browne has joined #openstack-keystone | 02:53 | |
| *** marcoemorais has joined #openstack-keystone | 02:54 | |
| *** shakayumi has quit IRC | 02:58 | |
| *** marcoemorais has quit IRC | 02:58 | |
| *** mberlin has joined #openstack-keystone | 02:58 | |
| *** mberlin1 has quit IRC | 02:59 | |
| *** marcoemorais1 has joined #openstack-keystone | 03:00 | |
| *** ncoghlan is now known as ncoghlan_afk | 03:00 | |
| *** ozialien has quit IRC | 03:10 | |
| *** xianghui has quit IRC | 03:12 | |
| nkinder | morganfainberg: writing the spec is on my list. I'll try to get a first draft going tomorrow. | 03:21 |
| *** bknudson has quit IRC | 03:23 | |
| *** sbfox has joined #openstack-keystone | 03:27 | |
| *** sbfox has quit IRC | 03:28 | |
| *** xianghui has joined #openstack-keystone | 03:29 | |
| *** dstanek_zzz is now known as dstanek | 03:35 | |
| *** dstanek is now known as dstanek_zzz | 03:45 | |
| *** hrybacki has joined #openstack-keystone | 03:46 | |
| *** hrybacki has quit IRC | 03:57 | |
| *** leseb has joined #openstack-keystone | 04:30 | |
| *** leseb has quit IRC | 04:35 | |
| *** dstanek_zzz is now known as dstanek | 04:36 | |
| *** dstanek is now known as dstanek_zzz | 04:46 | |
| *** afazekas has quit IRC | 04:55 | |
| *** zhiyan is now known as zhiyan_ | 05:13 | |
| *** ajayaa has joined #openstack-keystone | 05:28 | |
| *** ncoghlan_afk is now known as ncoghlan | 05:29 | |
| *** leseb has joined #openstack-keystone | 05:31 | |
| *** leseb has quit IRC | 05:35 | |
| *** zhiyan_ is now known as zhiyan | 05:35 | |
| *** dstanek_zzz is now known as dstanek | 05:36 | |
| morganfainberg | nkinder, ack. awesome! | 05:41 |
| morganfainberg | ayoung, ++ will review tomorrow | 05:43 |
| *** dstanek is now known as dstanek_zzz | 05:46 | |
| *** zhiyan is now known as zhiyan_ | 05:47 | |
| *** xianghui has quit IRC | 05:48 | |
| *** afazekas has joined #openstack-keystone | 05:57 | |
| *** xianghui has joined #openstack-keystone | 06:02 | |
| *** zhiyan_ is now known as zhiyan | 06:03 | |
| *** xianghui has quit IRC | 06:09 | |
| morganfainberg | ayoung, nkinder, either of you around? | 06:11 |
| morganfainberg | ayoung, nkinder, will bug you tomorrow early. | 06:12 |
| morganfainberg | (early for me) | 06:12 |
| *** tomoiaga has joined #openstack-keystone | 06:16 | |
| *** zhiyan is now known as zhiyan_ | 06:19 | |
| *** zhiyan_ is now known as zhiyan | 06:20 | |
| *** xianghui has joined #openstack-keystone | 06:23 | |
| *** praneshp has joined #openstack-keystone | 06:26 | |
| *** leseb has joined #openstack-keystone | 06:32 | |
| *** stevemar has quit IRC | 06:35 | |
| *** leseb has quit IRC | 06:37 | |
| *** dstanek_zzz is now known as dstanek | 06:37 | |
| *** browne has quit IRC | 06:37 | |
| *** dstanek is now known as dstanek_zzz | 06:47 | |
| *** xianghui has quit IRC | 06:56 | |
| *** xianghui has joined #openstack-keystone | 07:05 | |
| *** zhiyan is now known as zhiyan_ | 07:06 | |
| *** ncoghlan has quit IRC | 07:07 | |
| *** zhiyan_ is now known as zhiyan | 07:17 | |
| *** Camisa has joined #openstack-keystone | 07:30 | |
| *** Camisa has joined #openstack-keystone | 07:30 | |
| *** dstanek_zzz is now known as dstanek | 07:38 | |
| *** leseb has joined #openstack-keystone | 07:47 | |
| *** dstanek is now known as dstanek_zzz | 07:48 | |
| *** dstanek_zzz is now known as dstanek | 07:54 | |
| *** esmute has quit IRC | 07:55 | |
| *** jimbaker has quit IRC | 07:56 | |
| *** esmute has joined #openstack-keystone | 08:03 | |
| *** dstanek is now known as dstanek_zzz | 08:04 | |
| *** bvandenh has joined #openstack-keystone | 08:19 | |
| *** zhiyan is now known as zhiyan_ | 08:25 | |
| *** leseb has quit IRC | 08:37 | |
| *** leseb has joined #openstack-keystone | 08:37 | |
| *** leseb has quit IRC | 08:42 | |
| *** marekd|away is now known as marekd | 08:43 | |
| *** zhiyan_ is now known as zhiyan | 08:47 | |
| *** leseb has joined #openstack-keystone | 08:48 | |
| *** zhiyan is now known as zhiyan_ | 08:49 | |
| *** dstanek_zzz is now known as dstanek | 08:55 | |
| *** marcoemorais1 has quit IRC | 08:56 | |
| *** dstanek is now known as dstanek_zzz | 09:05 | |
| *** xianghui has quit IRC | 09:22 | |
| marekd | mhu: around? | 09:25 |
| mhu | marekd: hi ! | 09:29 |
| marekd | hi, thanks for the e-mail on the -dev list! | 09:29 |
| marekd | I am looking at the patch now. | 09:29 |
| marekd | Can you explain, why would you like to authenicate user present in Keystone backed via protocols like openid? | 09:31 |
| marekd | because i think that's the purpose of your patch? | 09:31 |
| mhu | marekd, the user isn't present in keystone, that's the aim of the patch | 09:34 |
| mhu | to use what you've done with saml but more generically | 09:34 |
| mhu | I want to mix what can be done with federation mapping, with the external auth process | 09:34 |
| marekd | ah, ok | 09:36 |
| marekd | mhu: and where is class Mapping used? | 09:37 |
| *** xianghui has joined #openstack-keystone | 09:38 | |
| mhu | marekd, I am thinking of using the federation protocol auth endpoint. I've documented a setup example for OpenID on this etherpad: https://etherpad.openstack.org/p/external-auth-federation-mapping | 09:38 |
| *** jaosorior has joined #openstack-keystone | 09:39 | |
| *** leseb has quit IRC | 09:44 | |
| *** leseb has joined #openstack-keystone | 09:44 | |
| marekd | hm, i don't think the logic is correct... | 09:48 |
| *** leseb has quit IRC | 09:49 | |
| *** zhiyan_ is now known as zhiyan | 09:49 | |
| marekd | mhu: first of all, in your example rule from the bp you will assign this group to *every* user who authenticates himself. This means for instance every CERN user from our 40k users ldap. | 09:50 |
| mhu | marekd, how so ? | 09:50 |
| mhu | marekd, yes, this has limitations inherent to the fact that you only get the remote_user env variable to make your mappings | 09:52 |
| mhu | so mappings can't be really granular | 09:52 |
| marekd | mhu: you are also discarding openid assertion and creating your own, which prevents me to create more restrictive rules.. | 09:53 |
| marekd | so again it's either I give access to all my CERN users or none of them...and I might want to give access to IT dep employees... | 09:53 |
| mhu | I was envisioning a simple use case, like giving a trial access for users on a public cloud, thus mapping to a restricted group | 09:53 |
| marekd | mhu: I think you may make it work eventually. | 09:54 |
| marekd | do you mind if I leave my comments on the patch? | 09:54 |
| mhu | marekd, please do ! help is welcome :) | 09:55 |
| *** dstanek_zzz is now known as dstanek | 09:55 | |
| marekd | ok :-) | 09:57 |
| mhu | marekd, while we're at it, I was wondering about supporting multiple idps for federation | 09:58 |
| marekd | uhm? | 09:58 |
| mhu | it is implied apache has to be reconfigured each time you add a protocol for a different idp ? | 09:58 |
| mhu | is it even possible with mod_shib ? | 09:58 |
| marekd | shib is saml2 only | 09:59 |
| *** zhiyan is now known as zhiyan_ | 09:59 | |
| marekd | so i'd say: if you want to add new proto, you will rather add new apache module and yes, reconfigure apache + add proto to keystone | 09:59 |
| mhu | yes, I meant protocol as the association idp + mapping in keystone | 09:59 |
| *** leseb has joined #openstack-keystone | 10:00 | |
| mhu | sorry for the confusion on my part :) | 10:00 |
| marekd | if you add new idp, then you add it via Keystone API and you also might need to add idp to shib oconfig, reloading apache too... | 10:00 |
| mhu | I need to look more into shib about this | 10:02 |
| *** praneshp has quit IRC | 10:03 | |
| mhu | but yeah, you'll definitely have to reload apache and add the LocationMatch directive that is needed | 10:03 |
| *** dstanek is now known as dstanek_zzz | 10:05 | |
| *** hxgqh1987 has joined #openstack-keystone | 10:07 | |
| *** hxgqh1987 has quit IRC | 10:07 | |
| marekd | mhu: for sure you can add multiple idps to shib | 10:09 |
| marekd | well, according to the specs :P | 10:09 |
| mhu | marekd, I'll believe it when I see it working :D | 10:09 |
| marekd | mhu: true. | 10:09 |
| mhu | anyway I am more "worried" about the apache config part that needs to be reloaded whenever you add an idp | 10:10 |
| *** leseb has quit IRC | 10:11 | |
| marekd | why? | 10:11 |
| mhu | there are some use cases where adding a new idp might happen relatively often | 10:13 |
| marekd | like? I thought federation is rather slow and static process (mainly due to many politics happening behind that) | 10:14 |
| *** dstanek_zzz is now known as dstanek | 10:14 | |
| mhu | marekd, gotta go now, but we'll resume the talk later if you want | 10:14 |
| marekd | drop me an email, hm? | 10:15 |
| marekd | i might be away | 10:15 |
| marekd | just got to europe and i might crash soon, as I am jetlaging still ;/ | 10:15 |
| *** leseb has joined #openstack-keystone | 10:17 | |
| *** bauzas has joined #openstack-keystone | 10:27 | |
| bauzas | hi | 10:27 |
| bauzas | python-keystoneclient-0.9.0 has been released yesterday, but now our gate is failing | 10:27 |
| bauzas | http://logs.openstack.org/42/96642/1/check/gate-blazar-python27/63f3b4a/ | 10:28 |
| bauzas | by reverting to 0.8.0, all is back to normal | 10:28 |
| bauzas | any chance to tell me how to fix this ? | 10:28 |
| bauzas | https://bugs.launchpad.net/keystone/+bug/1324861 | 10:37 |
| uvirtbot | Launchpad bug 1324861 in keystone "Pythonclient middleware auth's cache.set() is not expecting time as argument" [Undecided,New] | 10:38 |
| *** leseb has quit IRC | 10:49 | |
| *** leseb has joined #openstack-keystone | 10:49 | |
| *** zhiyan_ is now known as zhiyan | 10:50 | |
| *** leseb has quit IRC | 10:53 | |
| *** zhiyan is now known as zhiyan_ | 10:59 | |
| *** openstackgerrit has joined #openstack-keystone | 11:19 | |
| *** openstackgerrit has quit IRC | 11:19 | |
| *** openstackgerrit has joined #openstack-keystone | 11:25 | |
| marekd | What was the proper ordering of imports? First go stdlib modules (i.e. logging), later thirdparty modules (six), and lastly local modules? | 11:31 |
| openstackgerrit | A change was merged to openstack/keystone: Check that the user is dumb moved to the common method https://review.openstack.org/88517 | 11:45 |
| *** leseb has joined #openstack-keystone | 11:50 | |
| *** zhiyan_ is now known as zhiyan | 11:51 | |
| *** leseb has quit IRC | 11:54 | |
| *** leseb has joined #openstack-keystone | 11:55 | |
| *** zhiyan is now known as zhiyan_ | 12:00 | |
| *** bvandenh has quit IRC | 12:03 | |
| *** diegows has joined #openstack-keystone | 12:05 | |
| *** leseb has quit IRC | 12:09 | |
| dstanek | marekd: yep, you are correct | 12:12 |
| *** leseb has joined #openstack-keystone | 12:13 | |
| *** openstackgerrit has quit IRC | 12:22 | |
| *** openstackgerrit has joined #openstack-keystone | 12:22 | |
| *** rodrigods has joined #openstack-keystone | 12:27 | |
| *** rodrigods has joined #openstack-keystone | 12:27 | |
| marekd | dstanek: thanks... | 12:29 |
| openstackgerrit | Steven Hardy proposed a change to openstack/python-keystoneclient: Enable forcing re-authentication for trust-scoped clients https://review.openstack.org/96298 | 12:31 |
| *** rodrigods has quit IRC | 12:32 | |
| *** lbragstad has joined #openstack-keystone | 12:34 | |
| htruta | stevemar, thowe (away): sorry, I didn't understand your comment "Potentially, identity_client here" on the patch (https://review.openstack.org/#/c/91634/12/openstackclient/identity/v3/role_assignment.py) | 12:34 |
| marekd | jamielennox|away: do you want to take a look at: https://review.openstack.org/#/c/83829/ ? | 12:42 |
| ayoung | nkinder started it here https://review.openstack.org/#/c/96648/ | 12:44 |
| *** zhiyan_ is now known as zhiyan | 12:51 | |
| *** xianghui has quit IRC | 12:57 | |
| jaosorior | bauzas , the FakeMemCached there is in climate/tests/api/utils.py needs to have "time=0" instead of "timeout=None" | 12:58 |
| jaosorior | I tried doing it in your repo, but it seems that chaning it triggers a bunch of errors in the unit tests. mostly checks where it expected 403 status | 12:59 |
| bauzas | jaosorior: thanks for that, I figured it out 1 hour ago, and provided the patch in our branch | 13:00 |
| bauzas | jaosorior: should be merged soon | 13:00 |
| *** hrybacki has joined #openstack-keystone | 13:00 | |
| bauzas | jaosorior: sorry about the misunderstanding | 13:00 |
| *** zhiyan is now known as zhiyan_ | 13:03 | |
| jaosorior | no prob | 13:07 |
| *** ayoung_ has joined #openstack-keystone | 13:23 | |
| jaosorior | Hey, in the function authenticate_for_token, from Auth, in the module keystone/auth/controllers ; Is there a reason why the whole function is covered by a try: ... except ...? is it really necessary? or could I put the try ... except in the places where it could happen to simplify things? | 13:23 |
| *** bknudson has joined #openstack-keystone | 13:23 | |
| openstackgerrit | Ilya Pekelny proposed a change to openstack/keystone: oslo.db implementation https://review.openstack.org/77210 | 13:24 |
| openstackgerrit | Ilya Pekelny proposed a change to openstack/keystone: Use metadata.create_all() to fill a test database https://review.openstack.org/93558 | 13:24 |
| openstackgerrit | Ilya Pekelny proposed a change to openstack/keystone: Comparision of database models and migrations. https://review.openstack.org/80630 | 13:24 |
| *** dgbaley has quit IRC | 13:24 | |
| dstanek | jaosorior: it's difficult to do that now because we could break things | 13:28 |
| jaosorior | Keystone receives http messages asynchronously, right? | 13:31 |
| openstackgerrit | Vladimir Eremin proposed a change to openstack/keystone: Keystone compact PKI token https://review.openstack.org/96725 | 13:33 |
| dstanek | jaosorior: depends on what you mean by asynchronously and if you are running in apache | 13:33 |
| *** ayoung has quit IRC | 13:33 | |
| *** ayoung_ is now known as ayoung | 13:34 | |
| jaosorior | So, it could be processing two queries or commands related to the same trust at the same time? (not using apache) | 13:34 |
| *** ayoung_ has joined #openstack-keystone | 13:34 | |
| dstanek | yeah, i think that would be possible | 13:34 |
| jaosorior | ok, then probably I shouldn't move that try...except | 13:36 |
| openstackgerrit | Ionut Artarisi proposed a change to openstack/python-keystoneclient: allow a user's primary tenant to be modified https://review.openstack.org/96763 | 13:37 |
| *** gokrokve has joined #openstack-keystone | 13:37 | |
| *** nkinder has quit IRC | 13:40 | |
| openstackgerrit | Ionut Artarisi proposed a change to openstack/python-keystoneclient: allow a user's primary tenant to be modified https://review.openstack.org/96763 | 13:48 |
| *** leseb has quit IRC | 13:52 | |
| *** zhiyan_ is now known as zhiyan | 13:54 | |
| *** gordc has joined #openstack-keystone | 13:57 | |
| *** topol has joined #openstack-keystone | 13:59 | |
| openstackgerrit | Ilya Pekelny proposed a change to openstack/keystone: Use metadata.create_all() to fill a test database https://review.openstack.org/93558 | 14:00 |
| *** zhiyan is now known as zhiyan_ | 14:03 | |
| *** bobt has joined #openstack-keystone | 14:05 | |
| *** sbfox has joined #openstack-keystone | 14:06 | |
| *** stevemar has joined #openstack-keystone | 14:06 | |
| ayoung | morganfainberg, "Composite" doesn't seem like the right name for these tokens: https://review.openstack.org/#/c/96315/1 | 14:07 |
| ayoung | what are they "Composed" of? | 14:08 |
| ayoung | Seems more like a routing slip... | 14:08 |
| htruta | stevemar: ping | 14:08 |
| morganfainberg | ayoung, sure. we can name it something else | 14:09 |
| stevemar | htruta, pong | 14:09 |
| morganfainberg | ayoung, sec. need to discuss something else. | 14:09 |
| ayoung | morganfainberg, I'm trying to refresh my understanding.... | 14:09 |
| ayoung | OK | 14:09 |
| htruta | stevemar, thowe (away): sorry, I didn't understand your comment "Potentially, identity_client here" on the patch (https://review.openstack.org/#/c/91634/12/openstackclient/identity/v3/role_assignment.py) | 14:09 |
| *** rwsu has joined #openstack-keystone | 14:12 | |
| *** bauzas has left #openstack-keystone | 14:16 | |
| *** shakamunyi has joined #openstack-keystone | 14:22 | |
| *** leseb has joined #openstack-keystone | 14:23 | |
| *** henrynash has joined #openstack-keystone | 14:25 | |
| *** leseb has quit IRC | 14:28 | |
| *** dc_ has joined #openstack-keystone | 14:28 | |
| dc_ | does anyone have good documentation on making keystone HA? | 14:29 |
| *** hrybacki has quit IRC | 14:32 | |
| *** sbfox has quit IRC | 14:32 | |
| bknudson | got a minute for an auth_token middleware question? | 14:34 |
| *** comstud is now known as bearhands | 14:34 | |
| bknudson | when we store data in the cache, the data includes the expiration time: | 14:35 |
| bknudson | http://git.openstack.org/cgit/openstack/python-keystoneclient/tree/keystoneclient/middleware/auth_token.py#n936 | 14:35 |
| bknudson | the expiration time of the token | 14:35 |
| *** rodrigods has joined #openstack-keystone | 14:36 | |
| *** rodrigods has joined #openstack-keystone | 14:36 | |
| bknudson | but then it does _cache_get -- http://git.openstack.org/cgit/openstack/python-keystoneclient/tree/keystoneclient/middleware/auth_token.py#n1111 | 14:36 |
| bknudson | and it treats the expired time as more like the timeout of the cache | 14:36 |
| *** openstackgerrit has quit IRC | 14:36 | |
| bknudson | and not that the token is expired | 14:36 |
| *** openstackgerrit has joined #openstack-keystone | 14:37 | |
| bknudson | I'd expect _cache_get to "raise InvalidUserToken('Token authorization failed')" if the token in the cache was expired. | 14:38 |
| bknudson | that make sense? | 14:38 |
| *** nkinder has joined #openstack-keystone | 14:39 | |
| *** gokrokve has quit IRC | 14:40 | |
| *** dhellmann_ is now known as dhellmann | 14:40 | |
| ayoung | bknudson, it makes sense | 14:44 |
| *** leseb has joined #openstack-keystone | 14:44 | |
| ayoung | expires = confirm_token_not_expired(data) | 14:44 |
| ayoung | we take no chances that the cache expiration is longer than the expiration of the token | 14:45 |
| bknudson | why store the token expiration time in the cache if it's not used? | 14:45 |
| jaosorior | perhaps what was thought of is the possibility of the cache's expiration time being lower than the token's | 14:46 |
| bknudson | if the token expiration time is passed _cache_get just returns that the token isn't cached... it should raise the exception | 14:46 |
| bknudson | there's a cache expiration time and there's the token expiration time | 14:47 |
| bknudson | _cache_get doesn't know anything about the cache expiration time. | 14:47 |
| ayoung | bknudson, there might be some duplication here, but we have to check that the token is not expired if it is not in the cache. We might double check that for cached tokens | 14:47 |
| ayoung | bknudson, implcit | 14:47 |
| *** rodrigods has quit IRC | 14:47 | |
| ayoung | it can't get something out of the cache if the cache has expired | 14:47 |
| bknudson | The token is stored like this: cache.set(cache_key, data_to_store, time=self.token_cache_time) | 14:48 |
| bknudson | so the cache time and the token expiration time are independent | 14:48 |
| bknudson | which makes a bit of sense, we'll want to cache expired tokens rather than check every time | 14:49 |
| *** thedodd has joined #openstack-keystone | 14:52 | |
| *** zhiyan_ is now known as zhiyan | 14:55 | |
| *** gokrokve has joined #openstack-keystone | 14:59 | |
| *** gokrokve has quit IRC | 15:02 | |
| *** vhoward has left #openstack-keystone | 15:04 | |
| *** zhiyan is now known as zhiyan_ | 15:04 | |
| *** leseb has quit IRC | 15:06 | |
| openstackgerrit | Brant Knudson proposed a change to openstack/python-keystoneclient: auth_token _cache_get checks token expired https://review.openstack.org/96785 | 15:06 |
| openstackgerrit | Brant Knudson proposed a change to openstack/python-keystoneclient: auth_token cached token handling https://review.openstack.org/96786 | 15:06 |
| *** leseb has joined #openstack-keystone | 15:07 | |
| bknudson | ^ a couple proposals to change the behavior | 15:07 |
| *** leseb has quit IRC | 15:11 | |
| *** hrybacki has joined #openstack-keystone | 15:12 | |
| ayoung | I hereby dub dolphm 'Keystone 6' | 15:18 |
| dolphm | I hereby dub stevemar 'a door' | 15:21 |
| dolphm | mhu: are you Matthieu Huin? | 15:23 |
| stevemar | dolphm, mhu is Matt Huin | 15:25 |
| *** browne has joined #openstack-keystone | 15:26 | |
| openstackgerrit | Morgan Fainberg proposed a change to openstack/keystone-specs: Fix minor formatting in template https://review.openstack.org/96647 | 15:26 |
| dolphm | stevemar: i assume he's in a euro TZ? | 15:29 |
| stevemar | dolphm, y, in paris | 15:29 |
| stevemar | well, france, not sure where | 15:29 |
| dolphm | stevemar: don't be racist | 15:30 |
| *** leseb has joined #openstack-keystone | 15:30 | |
| * morganfainberg snickers | 15:30 | |
| stevemar | dolphm, what do i know, i'm just a door | 15:30 |
| dolphm | stevemar: i'm still wondering wtf that means | 15:31 |
| dolphm | ayoung: i also don't know what Keystone 6 means | 15:31 |
| morganfainberg | dolphm, talked w/ adrian_otto last night, Solum and nova docker will want the composite tokens as well. | 15:31 |
| stevemar | dolphm, i was trying really hard to remember a simpsons reference, but i butchered it | 15:31 |
| dstanek | dolphm: it means we're run out of good nams | 15:32 |
| morganfainberg | dolphm, i'm guessing Keystone 6 = sealteam 6 type thing | 15:32 |
| dstanek | errr...names | 15:32 |
| stevemar | dolphm, https://bestepisodeever.files.wordpress.com/2013/04/labf04a.jpg | 15:32 |
| dolphm | stevemar: so, 'a sign' would have made more sense? | 15:32 |
| mhu | dolphm: yup | 15:32 |
| ayoung | Radio Call Signs. Commander is the '6' by convention | 15:32 |
| morganfainberg | ayoung, ah. | 15:32 |
| * dolphm learned something new | 15:32 | |
| morganfainberg | ayoung, neat! | 15:32 |
| stevemar | dolphm, i already admitted that i butchered it | 15:32 |
| ayoung | Usually 1,2,3 are the leaders of the subordinate units, and 4 is the second in command. 5 is the Senior NCO (1st Sgt or CSM) | 15:34 |
| ayoung | So Keystone PTL is Keystone 6 | 15:34 |
| *** tomoiaga has quit IRC | 15:36 | |
| openstackgerrit | Dirk Mueller proposed a change to openstack/python-keystoneclient: Adjust Python 2.6 OSerror-on-EPIPE workaround https://review.openstack.org/96805 | 15:39 |
| *** hrybacki has quit IRC | 15:40 | |
| morganfainberg | ayoung, but... in Star Wars "Red 6" was just the sixth member of Red Squadron *duck* | 15:43 |
| ayoung | morganfainberg, true, they used Red Leader | 15:43 |
| morganfainberg | ayoung, >.> | 15:43 |
| morganfainberg | ayoung, so what would you call composite tokens... | 15:43 |
| ayoung | morganfainberg, "multiple tokens" I think. | 15:44 |
| ayoung | Er...no | 15:44 |
| dolphm | do backslash line continuations work in rst docs? | 15:44 |
| morganfainberg | dolphm, pretty sure they do | 15:44 |
| ayoung | these are tokens that represent permissions merged from multiple sources, right? | 15:44 |
| morganfainberg | ayoung, yes | 15:44 |
| dolphm | morganfainberg: is that a better way to format URLs within 79 chars? | 15:44 |
| morganfainberg | dolphm, probably. if so i'll put a quick >79 char line test into specs repo | 15:45 |
| ayoung | Collaborative Tokens? | 15:45 |
| ayoung | Joint Tokens? | 15:45 |
| dolphm | morganfainberg: that'd be nice | 15:46 |
| morganfainberg | dolphm, will work on that today. | 15:46 |
| dolphm | Twinsy Tokens | 15:46 |
| morganfainberg | dolphm, ++ | 15:46 |
| nkinder | mutual tokens? | 15:47 |
| ayoung | Wonder Twin Tokens | 15:47 |
| morganfainberg | ayoung, hahah was going there next | 15:47 |
| dolphm | class MutuallyFamilialOftenCollaborativeTokenCompositionProcessorator(object): | 15:47 |
| *** ozialien has joined #openstack-keystone | 15:47 | |
| ayoung | dolphm, wins | 15:47 |
| nkinder | dolphm: is that >79 chars? :) | 15:48 |
| dolphm | this crap implements itself | 15:48 |
| dolphm | nkinder: dammit | 15:48 |
| morganfainberg | dolphm, can you get the class name > 120 characters so no one can ever use it. | 15:48 |
| dolphm | morganfainberg: rofl | 15:48 |
| ayoung | OK, so the tokens themselves are nothing special, right? It is the process by which they are created that is different? | 15:49 |
| dolphm | ayoung: yeah | 15:49 |
| morganfainberg | ayoung, they will contain some extra information (e.g. composite from token id X, X, X) but otherwise they are a normal token | 15:49 |
| *** matsuhashi has joined #openstack-keystone | 15:50 | |
| *** fmarco76 has joined #openstack-keystone | 15:50 | |
| morganfainberg | or... some kind of information indicating what generated them. | 15:50 |
| morganfainberg | realizing token_id might be bad... you know... PKI token ids being so long | 15:50 |
| dolphm | i think we need to work on separating token audit information far away from the tokens themselves, otherwise it's going to bloat like crazy | 15:51 |
| openstackgerrit | A change was merged to openstack/keystone-specs: Fix minor formatting in template https://review.openstack.org/96647 | 15:51 |
| morganfainberg | dolphm, yes. this is more for revocation abilities | 15:51 |
| morganfainberg | dolphm, if you revoke either of the originating tokens we need to be able to revoke this one | 15:51 |
| morganfainberg | dolphm, or ... will that even work? | 15:52 |
| ayoung | lets call them joint tokens. Its short, and the humor will play along with Keystoners. | 15:52 |
| * morganfainberg is thinking revocation events. | 15:52 | |
| morganfainberg | ayoung, that works for me. | 15:53 |
| *** david-lyle has joined #openstack-keystone | 15:53 | |
| ayoung | morganfainberg, could they be created from a trust instead of multiple tokens? | 15:53 |
| ayoung | like: these two user get together, form a corporation, and start issuing tokens? | 15:53 |
| morganfainberg | ayoung, from a UX needing to create a trust, then tell the service to use that trust - it's a lot less natural | 15:53 |
| ayoung | None of this is natural. | 15:54 |
| ayoung | Keystone is unnatural | 15:54 |
| ayoung | Computers even more so | 15:54 |
| morganfainberg | ayoung, ux perspective handing a token over to the service and the service can just work with it is way better | 15:54 |
| ayoung | morganfainberg, there is something wrong there... | 15:54 |
| morganfainberg | ayoung, vs. needing to go stand up a bunch of things then somehow tell that service to use this new thing. | 15:54 |
| morganfainberg | ayoung, the trust workflow (especially when you talk about having a large number of actions) is very clunky | 15:55 |
| ayoung | morganfainberg, only because it is new. We can streamline it. But I need to check out for a few minutes.... | 15:55 |
| *** ayoung is now known as ayoung-afk | 15:55 | |
| *** zhiyan_ is now known as zhiyan | 15:56 | |
| *** hrybacki has joined #openstack-keystone | 15:56 | |
| *** dstanek is now known as dstanek_zzz | 15:56 | |
| morganfainberg | ayoung-afk, i think using trusts here isn't the right answer - we talked through the possibilitiys for explicit delegation and having to do <grant delegation> to <service>, ask service to do <thing> service use <trust> was a lot of changes in a lot of places. | 15:57 |
| morganfainberg | ayoung-afk, discuss more when you're back | 15:57 |
| dolphm | ++ composite tokens *was* the streamlined solution | 16:01 |
| *** ozialien has quit IRC | 16:02 | |
| *** browne has quit IRC | 16:04 | |
| *** zhiyan is now known as zhiyan_ | 16:05 | |
| morganfainberg | dolphm, I'm seeing requests for a simple-shared-secret auth mechanism again. but what is really wanted is a way to say give me a token for user X scoped to Y with specific roles. [i've been digging into the real use-cases here] | 16:06 |
| *** sbfox has joined #openstack-keystone | 16:06 | |
| dolphm | morganfainberg: that's a fair use case, but what does it have to do with the proposed solution? sounds like oauth | 16:07 |
| dolphm | morganfainberg: last time simple-shared-secret came up, the only use case we got out of it was for password rotation | 16:07 |
| morganfainberg | dolphm, right and this is the same thing again, but i've been asking more questions about what is really wanted | 16:07 |
| morganfainberg | dolphm, this does sound a lot like oauth | 16:08 |
| *** leseb has quit IRC | 16:09 | |
| morganfainberg | dolphm, i don't think i'd use the proposed solution as it was | 16:09 |
| *** leseb has joined #openstack-keystone | 16:09 | |
| *** sbfox1 has joined #openstack-keystone | 16:09 | |
| morganfainberg | dolphm, it would need to be something new. | 16:09 |
| dolphm | morganfainberg: or oauth? lol | 16:10 |
| morganfainberg | dolphm, i mean if oauth isn't the right answer | 16:10 |
| morganfainberg | dolphm, let me go look at oauth and see if it'll work -- if not what we need to do to fix it | 16:10 |
| morganfainberg | for this usecase. | 16:10 |
| dolphm | morganfainberg: ack | 16:11 |
| *** sbfox has quit IRC | 16:11 | |
| morganfainberg | actually... gonna go get coffee and breakfast first instead. | 16:11 |
| stevemar | mhu, ping? | 16:14 |
| *** leseb has quit IRC | 16:14 | |
| fmarco76 | hello guys | 16:14 |
| stevemar | fmarco76, hello! | 16:14 |
| fmarco76 | if I would commit a spec and send to review, what should I put in the commit message? | 16:14 |
| stevemar | fmarco76, something like this https://review.openstack.org/#/c/96315/ | 16:15 |
| fmarco76 | have to put "Implements: blueprint xxxxxxxxxxxxxx" | 16:15 |
| stevemar | fmarco76, bp xxxxxxxx | 16:16 |
| fmarco76 | OK, thanks | 16:16 |
| *** dstanek_zzz is now known as dstanek | 16:17 | |
| *** richm has joined #openstack-keystone | 16:18 | |
| *** ajayaa has quit IRC | 16:19 | |
| *** shakamunyi has quit IRC | 16:20 | |
| *** thedodd has quit IRC | 16:21 | |
| *** thedodd has joined #openstack-keystone | 16:23 | |
| *** fmarco76 has quit IRC | 16:25 | |
| openstackgerrit | OpenStack Proposal Bot proposed a change to openstack/keystone: Updated from global requirements https://review.openstack.org/91225 | 16:26 |
| *** leseb has joined #openstack-keystone | 16:28 | |
| *** praneshp has joined #openstack-keystone | 16:29 | |
| *** leseb has quit IRC | 16:29 | |
| *** daneyon has joined #openstack-keystone | 16:31 | |
| *** ericvw has quit IRC | 16:32 | |
| openstackgerrit | OpenStack Proposal Bot proposed a change to openstack/python-keystoneclient: Updated from global requirements https://review.openstack.org/96265 | 16:32 |
| *** gokrokve has joined #openstack-keystone | 16:36 | |
| *** gokrokve_ has joined #openstack-keystone | 16:37 | |
| *** gokrokve has quit IRC | 16:40 | |
| *** browne has joined #openstack-keystone | 16:45 | |
| *** ayoung-afk is now known as ayoung | 16:46 | |
| ayoung | morganfainberg, OK...one step at a time | 16:46 |
| ayoung | a User needs to be able to request a token with a subset of roles, and targetted to a specific endpoint | 16:47 |
| ayoung | We endd endpoint binding of tokens before anything else will work scoping wise, I think | 16:47 |
| ayoung | that is an Auth Token Middleware issue to solve | 16:47 |
| ayoung | Adding explicit roles into the token request is a stand alone change that can happen in parallel, and nkinder expressed an interest in that as well. | 16:48 |
| morganfainberg | I disagree that we need endpoint binding before anything else. its something very nice to have, but far from required. | 16:48 |
| ayoung | that is going to be somewhat broken if a user can request a token to get another token | 16:48 |
| ayoung | morganfainberg, just within keystone: | 16:48 |
| ayoung | if a token does not have keystone in the service catalog, keystone shouldn't honor it | 16:48 |
| ayoung | so I should be able to get a token, hand it to nova, and not worry that someone is going to upgrade it for another token | 16:49 |
| *** sbfox1 has quit IRC | 16:50 | |
| morganfainberg | ayoung, again, a very nice to have and i want to see it. but i disagree with it being a hard requirement, we don't have it today. and it wont change much from today if we don't get it | 16:50 |
| ayoung | morganfainberg, lets agree that it is necessary, and we can work out the dependencies and ordering later? | 16:50 |
| dstanek | won't endpoint binding be confusing for users? they'll have to know what services will be talking to what other services right? | 16:50 |
| morganfainberg | ayoung, absolutely, i was going to just offer that it should be worked orthogonally to joint tokens. | 16:50 |
| ayoung | dstanek, not really. To start with, we just use the endpoint filtering | 16:50 |
| ayoung | per project | 16:50 |
| morganfainberg | ayoung, orthogonally to most of the other work. adding the endpoint binding should have no other impact. | 16:51 |
| ayoung | dstanek, the question is what to do with tokens that have no service catalog in them, which is what we've been telling people is the work-around for token size...but compression should manage that | 16:51 |
| *** Ju has quit IRC | 16:52 | |
| ayoung | morganfainberg, so, for workflow, where a user goes to nova, then nova goes to glance, and glance goes to swift, that is why you want the joint tokens, right? | 16:52 |
| morganfainberg | ayoung, correct - preventing user X from changing something in swift (for example) directly | 16:52 |
| dstanek | ayoung: what to do? are you talking client side or server side? | 16:52 |
| morganfainberg | but also prventing compromise of glance from changing everythign in swift | 16:53 |
| morganfainberg | two keys to launch. | 16:53 |
| dstanek | morganfainberg: like a nuclear missle! | 16:53 |
| morganfainberg | dstanek, except you trade both bits in for the launch code :P | 16:54 |
| *** sbfox has joined #openstack-keystone | 16:54 | |
| ayoung | morganfainberg, so the trick is for nova to be able to add an additional limitation on a token...Ideally we would let Nova sign a new token, but with a way of confirming that it was only contianing a limited set of the data from the origianl token, without letting someone else strip out the origianl token and just use that | 16:54 |
| morganfainberg | ayoung, correct, and in theory glance should be able to do the same with the joint token it gets from nova (if needed) | 16:54 |
| ayoung | morganfainberg, so why not have the user request all that up front? | 16:55 |
| ayoung | "I'm launching a VM, give me a token scoped from Nova to Glance" | 16:55 |
| ayoung | and I need to go pickup food now...back in a few | 16:55 |
| *** ayoung is now known as ayoung_fuud | 16:55 | |
| morganfainberg | ayoung_fuud, how does the user know he needs a glance token? or more to the point a glance and swift token? | 16:56 |
| *** zhiyan_ is now known as zhiyan | 16:56 | |
| morganfainberg | ayoung_fuud, the user mostly only knows he wants to launch a VM and that requires talking to nova. | 16:56 |
| * morganfainberg does the same and actually gets food and coffee. | 16:56 | |
| dstanek | i've often wondered about using tokens that are not bearer tokens | 17:00 |
| *** nkinder has quit IRC | 17:01 | |
| morganfainberg | dstanek, a token that is explicitly scoped to a single action? | 17:03 |
| *** marcoemorais has joined #openstack-keystone | 17:03 | |
| *** ozialien has joined #openstack-keystone | 17:04 | |
| *** richm has left #openstack-keystone | 17:04 | |
| dstanek | morganfainberg: no, i was thinking more oauth based signatures | 17:04 |
| morganfainberg | ah | 17:04 |
| dstanek | if i want nova to do something on my behalf i could do a negotiation (kinda like kerberos) that gives the nova service a token that only it can use | 17:05 |
| *** zhiyan is now known as zhiyan_ | 17:06 | |
| dstanek | i think part of the (or my) confusion is that services can use other services for a user or on behalf of a user | 17:06 |
| dstanek | nova stores stuff in glance on behalf of a user and the user can look in glance and see images and snapshots | 17:07 |
| dstanek | glance uses swift for a user to store their data, but the user doesn't see this raw data | 17:07 |
| openstackgerrit | Marco Fargetta proposed a change to openstack/keystone-specs: Web Authentication for SAML federated Keystone https://review.openstack.org/96867 | 17:09 |
| stevemar | dolphm, marekd ^ | 17:11 |
| morganfainberg | dstanek, yeah. | 17:11 |
| *** dims has joined #openstack-keystone | 17:13 | |
| *** nkinder has joined #openstack-keystone | 17:14 | |
| *** harlowja_away is now known as harlowja_ | 17:15 | |
| *** dims is now known as dimsum | 17:16 | |
| *** richm1 has joined #openstack-keystone | 17:19 | |
| *** ayoung_fuud is now known as ayoung | 17:20 | |
| ayoung | dstanek, that was the endpoint binding I was talking about | 17:21 |
| ayoung | dstanek, the things is, Nova is really a workflow engine. Something needs to orchestrate the workflow | 17:22 |
| ayoung | morganfainberg, dstanek the thing is, endpoint binding is really simple, if the endpoints know their own endpoint id. "Endpoint must be in the catalog" | 17:24 |
| *** fmarco76 has joined #openstack-keystone | 17:25 | |
| dstanek | ayoung: if you do it that way what will nova use to talk to glance? | 17:26 |
| *** fmarco76 has left #openstack-keystone | 17:26 | |
| ayoung | dstanek, to start with, the same token | 17:26 |
| ayoung | you could make a token with both nova and glance in it | 17:26 |
| ayoung | assuming you had different roles for each service, you could restrict things fairly easily | 17:27 |
| ayoung | 1 role is launch_vm the other is fetch_image | 17:27 |
| ayoung | we don't need a new mechanism, we need to make better use of the mechanisms we have to enforce that | 17:27 |
| *** radez_g0n3 is now known as radez | 17:31 | |
| dstanek | ayoung: that doesn't help glance verify that nova or anything else is allowed to use that token | 17:31 |
| ayoung | dstanek, true. It is still a bearer token | 17:31 |
| ayoung | dstanek, you could make is a single use token. Glance accepts it, hands out the image, and then sticks the token in the revocation list. | 17:34 |
| dstanek | ayoung: who would revoke it nova, glance or swift? | 17:37 |
| ayoung | Glance | 17:37 |
| ayoung | dstanek, and swift could do the same thing | 17:37 |
| dstanek | so how would glance get a token to use with swift? | 17:37 |
| ayoung | so if the token goes from nova to glance, glance accepts it once. THne glance passes to swift, and swift accepts it once | 17:37 |
| bknudson | nova probably needs it for neutron too | 17:38 |
| ayoung | the "single use" policy is specified in the token, and enforced on the endpoints | 17:38 |
| *** sbfox has quit IRC | 17:39 | |
| ayoung | bknudson, yep, and the same rule would apply there. | 17:40 |
| ayoung | It could even be a counter: use it X number of times on endpoint Y | 17:40 |
| ayoung | the alternative would be something like this: | 17:41 |
| bknudson | when I get a token I need to know if nova is configured for neutron or not? | 17:41 |
| dstanek | bknudson: worse...you have to know that the instance of glance used by nova uses swift as a backend | 17:42 |
| ayoung | user goes directly to glance and tells glance: let endpoint E fetch image I. Glance responds with: I'm going to need permissions from Swift to do that, and also returns a cookie. So user goes to Swift and says, let Glance Endpoint G fetch object O. Swift holds on to that preauth, and passes a cookie back to the user. The user then hands both of these cookies over to Nova | 17:43 |
| ayoung | dstanek, put the onus of all that on the Service Catalog | 17:43 |
| ayoung | "everything that this token is expected to work with is in this catalog" | 17:43 |
| dstanek | ayoung: how do you show in the catalog that glance uses a swift backend? swift may be in there just because the user has access to it | 17:44 |
| *** afazekas has quit IRC | 17:44 | |
| bknudson | could the user go to glance and say "let endpoint E fetch image I using this cookie" | 17:45 |
| ayoung | dstanek, is that common? | 17:45 |
| ayoung | bknudson, it could all be prearrainged, and signed by a users private key if you really wanted | 17:45 |
| dstanek | no idea...it was a topic of conversation at the summit | 17:46 |
| ayoung | user would not even hav to go to glance to set that up, just have the workflow set up ahead of time | 17:46 |
| bknudson | it could just be "let this image be fetched using this cookie" | 17:46 |
| bknudson | since glance shouldn't need to know that a particular endpoint is going to be doing it. | 17:47 |
| ayoung | bknudson, why not? Then anyone can fetch it. | 17:48 |
| bknudson | if they have the cookie they could. how would they get the cookie unless the user gave it to them? | 17:48 |
| dstanek | bknudson: i like the idea of signatures so glance could verify that nova was allowed to reuse that token | 17:49 |
| bknudson | so it would be signed with nova's public key? | 17:50 |
| nkinder | ayoung: the composite token idea seems much cleaner to me | 17:51 |
| ayoung | nkinder, why> | 17:52 |
| dstanek | bknudson: something like that | 17:52 |
| dstanek | bknudson: i'm not proposing any changes right now, i've just been thinking about how to get rid of bearer tokens | 17:52 |
| nkinder | ayoung: for one, we don't have a slew of revocation events like we would for the one time use tokens | 17:53 |
| nkinder | ayoung: two, the user doesn't have to know what services talk to what other services on the back-end | 17:53 |
| dstanek | nkinder: what is the token a composite of? | 17:54 |
| nkinder | two separate parties (the real user and the service user) are both agreeing on an action | 17:54 |
| ayoung | nkinder, how do they agree? | 17:54 |
| nkinder | dstanek: a token from the real user and a token from the service user | 17:54 |
| dstanek | nkinder: ah, right. i think that is similar to what i was thinking | 17:56 |
| nkinder | ayoung: it is true that the user doesn't really know what a service might do with it's token | 17:56 |
| nkinder | ayoung: but the composite token prevents the service user from performing an action without possession of a user token that is authorized | 17:56 |
| nkinder | the service user can't perform the action alone, and neither can the user | 17:57 |
| dstanek | nkinder: right, i just want to say 'i trust nova to do X on my behalf' and if nova feels the need to talk to something else i wouldn't care | 17:57 |
| nkinder | dstanek: exactly | 17:57 |
| ayoung | nkinder, how common is it that such an action would never be authorized? | 17:57 |
| *** zhiyan_ is now known as zhiyan | 17:57 | |
| nkinder | ayoung: I don't have any statistics. Perhaps dolphm does, as he was who I heard the use case from. | 17:58 |
| ayoung | nkinder, the problem is that we don't know what nova is going to do on a users behalf. That is why I want to solve things at the policy/audit level before purusing more delegation mechanisms | 17:59 |
| nkinder | ayoung: I don't really see it as delegation, as the user isn't saying "you(glance) can talk to swift on my behalf" | 18:02 |
| nkinder | the user is just saying "I'm me. Perform this glance operation." | 18:02 |
| ayoung | nkinder, the number one threat I want to defend against is where a Hypervisor compromise gets access tpo general purpose tokens. Everything else, is, I think secondary to that. But the MOC approach makes things more interesting: | 18:03 |
| ayoung | if Nova is run by HP, Swift by EMC, and Glance by Red Hat, no one trusts anyone | 18:03 |
| *** praneshp has quit IRC | 18:04 | |
| ayoung | the end use wants to say "here is my workflow. THis and this alone is authorized" | 18:04 |
| ayoung | but right now, we don't know what that workflow really is | 18:04 |
| *** gyee has joined #openstack-keystone | 18:04 | |
| ayoung | nkinder, and, in this case, the user is saying "its ok if nova gets access to my glance image stored in my swift account" | 18:04 |
| openstackgerrit | Brant Knudson proposed a change to openstack/keystone-specs: Template cleanup - RST docs https://review.openstack.org/96886 | 18:05 |
| morganfainberg | ayoung, no, it's the user saying "it's ok for nova to access the image in glance that happens to be stored in swift, but glance can't do it alone" the user wouldn't be able to get the glance image w/o going through glance either | 18:06 |
| morganfainberg | ayoung, similarly nova couldn't do it alone. | 18:06 |
| ayoung | morganfainberg, why should a user not be able to fetch their own image? | 18:06 |
| *** zhiyan is now known as zhiyan_ | 18:06 | |
| bknudson | once glance has gotten the image once it can just save it off somewhere | 18:06 |
| morganfainberg | ayoung, because it isn't owned by the user. it is managed by glance on behalf of the user | 18:07 |
| bknudson | Did I sign my image so that I can trust that the right image was used? | 18:07 |
| ayoung | morganfainberg, so this is the case where corporate uploads a special image, and people in their org can use that image on a set of nova machines, but can't download it to transport it around? | 18:08 |
| bknudson | I could sent nova a hash of the image and hope it verifies | 18:08 |
| morganfainberg | ayoung, more to the point, the user uploads an image to glance. Glance stores said image (and metadata) | 18:08 |
| *** sbfox has joined #openstack-keystone | 18:08 | |
| morganfainberg | ayoung, user wants to perform some kind of update. you want glance to control that update. but only if the user requests it | 18:09 |
| ayoung | morganfainberg, so the user already has access to the image, why should they not be able to download it again directly? Why should it not be usable on every Nova in the Datacenter? Why should they not be able to provide access to it to some other service? | 18:09 |
| morganfainberg | ayoung, if it was just "stored in swift" the user could update w/o glance knowing | 18:09 |
| morganfainberg | ayoung, similarly, compromise of glance service user couldn't directly update images w/o the user's concent [token] as well | 18:10 |
| dstanek | the use-case i heard at the summit is that a user can see their images in glance, but not in swift (even though they are actually stored there) | 18:10 |
| dstanek | the use doesn't know or need to know that they are in swift | 18:10 |
| morganfainberg | ayoung, because you've asked glance to manage it. do you know where glance stores images? do you care? | 18:10 |
| morganfainberg | ayoung, as an end user | 18:10 |
| ayoung | morganfainberg, again, it is solvable by current policy. If I want to mess myself up, I should be able to do so. If an org wants to say "all modifications to GLance must go through glance" that can be done today, too | 18:11 |
| *** erecio has joined #openstack-keystone | 18:11 | |
| ayoung | morganfainberg, its based on the glance config, I assume. I assume glance has the ability tpo make multiple choices, or I need multiple glance instances for that? | 18:11 |
| morganfainberg | ayoung, if you use the current policy and glance stores an image in swift either a) the user can change, not through glance | 18:11 |
| morganfainberg | ayoung or b) glance can change w/o the user. | 18:12 |
| ayoung | glance can do whatever it wants. It could change the image on the fly if it is compromised | 18:12 |
| morganfainberg | ayoung, not the glance service, the glance user. if keystone is compromised (itself) we're screwed. i accept if the service is in-memory compromised there is nothing we can do | 18:13 |
| morganfainberg | if any service itself is compromised we are kinda SOL. | 18:13 |
| *** hrybacki has quit IRC | 18:14 | |
| ayoung | morganfainberg, the glance user does not talk to swift. If glance talks to swift today, it passes the owning users token. Where does the glance use come into play> | 18:14 |
| nkinder | ayoung: the glance user comes into play from the idea of composite tokens | 18:15 |
| morganfainberg | ayoung, the point is you don't want the user to have access to change the swift store that glance is using. glance _needs_ to know each change. so you'd have a glance user to create the composite token | 18:15 |
| nkinder | we don't want the user to be able to download the image | 18:15 |
| nkinder | ...directly from swift | 18:15 |
| ayoung | nkinder, the glance user should actually be going away. Right now it is needed only to talk to keystone to fetch revocation information and certs. | 18:15 |
| ayoung | nkinder, then the user should be using someone elses storage, and some sort of proxy arraingment needs to be set up with glance. | 18:16 |
| morganfainberg | ayoung, service users aren't going away | 18:16 |
| morganfainberg | ayoung, they just wont be. | 18:16 |
| ayoung | morganfainberg, they should not be increasing in responsibility | 18:16 |
| morganfainberg | ayoung, why? | 18:16 |
| ayoung | morganfainberg ... how important is the Voltron Token? | 18:17 |
| morganfainberg | ayoung, we have (so far) 3 confirmed use cases | 18:18 |
| morganfainberg | ayoung, glance, solum, and use for nova+docker | 18:18 |
| morganfainberg | ayoung, well glance+swift | 18:18 |
| morganfainberg | ayoung, oh, 4, barbican and user-secrerts | 18:18 |
| *** erecio has quit IRC | 18:19 | |
| *** erecio has joined #openstack-keystone | 18:19 | |
| morganfainberg | ayoung, lets try this from the other angle -- how would you setup the proxy arrangement with glance? how does the end user handle that. [think end user managing an image], | 18:21 |
| morganfainberg | uploading for users to utilize (public) in nova | 18:21 |
| ayoung | morganfainberg, I'm not certain that the use case as presented is the general use case. I don't have enough information to confirm, but I do know that it sounds like the composite tokens are a very specific mechanism. I'm wary. Just trying to understand, but I've been thinking about this problem for a long, long time, and that is not one of the major use cases I've confronted. | 18:23 |
| *** bobt has quit IRC | 18:24 | |
| ayoung | morganfainberg, oooh...just discovered restview | 18:24 |
| ayoung | http://mg.pov.lt/restview/ | 18:25 |
| morganfainberg | ayoung, thats cool! | 18:25 |
| topol | ayoung++ restview looks really cool | 18:28 |
| ayoung | morganfainberg, OK, lets nail down the use case, before we hit the solution. I'm going to use the Whiteboard on the BP for this: | 18:28 |
| morganfainberg | ayoung, lets do etherpad | 18:28 |
| ayoung | morganfainberg, that works, too: | 18:29 |
| morganfainberg | https://etherpad.openstack.org/p/keystone-joint-tokens | 18:29 |
| morganfainberg | nkinder, ^ if you want to jump in | 18:29 |
| morganfainberg | nkinder, since you were also around for the original discussion at the summit | 18:30 |
| ayoung | morganfainberg, so the big thing I want to point out is that if any of these operations are going to take place outside of direct involvement of the user (token expired) they are going to require a trust or oauth. | 18:32 |
| ayoung | Kicking off a VM is already a known issue: | 18:33 |
| morganfainberg | assume the use cases here do not involve an expired user-token | 18:33 |
| morganfainberg | we aren't orchestrating e.g. heat | 18:35 |
| morganfainberg | so single op, which a token should be valid for. | 18:35 |
| bknudson | user doesn't know how long their op is going to take | 18:35 |
| morganfainberg | and if it's not and everything has to be trusts, we are doing a lot of things wrong | 18:35 |
| morganfainberg | bknudson, sure. | 18:36 |
| bknudson | even with trusts you have the expiration issue -- how long does it take to get a trust? | 18:36 |
| morganfainberg | bknudson, in theory a service user could use a trust. | 18:37 |
| morganfainberg | bknudson, so less of an issue i guess | 18:37 |
| ayoung | morganfainberg, trusts are a delegation mechanism. THey have certain drawbacks, the biggest of which is that they require the delegated entity to be another Keystone user. But that does not mean we cannot expand on what is meant by a trust in order to make this work. What a bout Group trusts? | 18:37 |
| ayoung | trusts do not have to expire bknudson | 18:37 |
| bknudson | ayoung: right, but you need an unexpired token to get a trust | 18:38 |
| ayoung | bknudson, the service user has to have that anyway | 18:38 |
| morganfainberg | bknudson, service user would do that in this case | 18:38 |
| *** marcoemorais has quit IRC | 18:38 | |
| bknudson | I do nova boot with a token and nova uses it to get a trust | 18:38 |
| morganfainberg | ayoung, my biggest concern with a trust is how do you know what trust to use (as a service user) to do the nova boot | 18:38 |
| ayoung | bknudson, that really should be : user has to be authenticated | 18:38 |
| bknudson | but maybe that token was just about to expire | 18:38 |
| *** praneshp has joined #openstack-keystone | 18:38 | |
| bknudson | or do I pass a trust token to nova on boot? | 18:39 |
| morganfainberg | ayoung, X-AUTH-TOKEN: blah, http://nova/boot_instance {instance info} | 18:39 |
| ayoung | morganfainberg, how about a general purpose query: Please use the trust that is relevant for this operations: | 18:39 |
| *** marcoemorais has joined #openstack-keystone | 18:39 | |
| morganfainberg | ayoung, i have 5 trusts to nova for various things, which one? | 18:39 |
| ayoung | morganfainberg, instead of create token for trust based on id, it would be create token for trust based on trustor/trustee/role | 18:40 |
| *** rodrigods has joined #openstack-keystone | 18:40 | |
| *** rodrigods has joined #openstack-keystone | 18:40 | |
| ayoung | If I only care about a specific role, just give me the first that fits. | 18:40 |
| *** sbfox has quit IRC | 18:40 | |
| morganfainberg | ayoung, how do you know what role is needed? | 18:41 |
| ayoung | what if we define the trust on the project, not the user | 18:42 |
| ayoung | any user that is a member of this project is enrolled in a trust relationship with the endpoints. | 18:42 |
| morganfainberg | ayoung, i'm not saying we can't do all this with trusts, but we need the UX for booting up and instance (example use case) to remain mostly the same - asking a whole lot more mechanism will make it so no one migrates to the new system and hacks around it | 18:42 |
| ayoung | morganfainberg, I think I am just coming up with a way to implement your blueprint in the context of trusts... | 18:43 |
| ayoung | A trust is already a way of creating a contract between two endpoints. | 18:43 |
| ayoung | well, a user is really not an endpoint, but | 18:43 |
| morganfainberg | ayoung, ok lets explore project | 18:43 |
| ayoung | so a project admin sets up a series of trusts. One if for glance to talk to swift | 18:44 |
| morganfainberg | ayoung, everything is really project scoped not user scoped anyway | 18:44 |
| ayoung | ++ | 18:44 |
| ayoung | and with the endpoint filter, we have a clean way of associating endpoints with projects | 18:44 |
| ayoung | So, we make a bunch of implicit trusts. | 18:45 |
| morganfainberg | ayoung, lets leave the endpoint filter off - we'll def get there | 18:45 |
| morganfainberg | but it doesn't impact the design (we know we want it and will implement it) | 18:45 |
| ayoung | morganfainberg, the endpoint filter makes the whole thing much clearer, as it says which specific endpoints are enrolled in the trust | 18:45 |
| ayoung | but anyway.... | 18:46 |
| morganfainberg | ok, so project admin needs to know about cloud deployment to build the trusts? | 18:46 |
| morganfainberg | that glance uses swift? | 18:46 |
| *** arunkant has joined #openstack-keystone | 18:47 | |
| ayoung | OK, so for project P, we create a trust that says Nova can get a token on behalf of a user with role "fetch_from_glance" in Project P only | 18:47 |
| morganfainberg | and the roles to delegate | 18:47 |
| ayoung | also for project P, we create a trust that says Glance can get a token on behalf of a user with role "fetch_from_swift" in Project P only | 18:47 |
| morganfainberg | so far with you on the mechanism. | 18:48 |
| morganfainberg | and what the trust structure looks like | 18:48 |
| ayoung | Now, this does not say that the user kicked off the use case | 18:48 |
| ayoung | glance can perform it at any time | 18:48 |
| ayoung | to get to where you are, glance should have to add to the request the token from nova | 18:48 |
| morganfainberg | ayoung, which breaks the 'compromise of the glance service user shoudln't be able to be malicious to everything" [in this case] | 18:48 |
| morganfainberg | ayoung, ok, so how does that end up working. | 18:49 |
| *** marcoemorais has quit IRC | 18:49 | |
| ayoung | morganfainberg, I think we are solving the wrong problem. The user can preauthorize anything. THe problem is that we don't know what to pre-authorize | 18:50 |
| ayoung | So, yeah, we could add "and you need an active user token to activate the trust" | 18:50 |
| ayoung | that only limits things if that user token alone couldn't be used to talk to swift | 18:50 |
| morganfainberg | ayoung, which was one of the clear desires. | 18:51 |
| ayoung | I'd rather have the user get a bunch of tokens up front, and hand them off to the services. No round trip to Keystone required | 18:51 |
| ayoung | Instead of One token, the user gets one per endpoint | 18:51 |
| morganfainberg | ayoung, but the user shouldn't have to know what tokens to get | 18:51 |
| ayoung | Someone needs to set this up ahead of time. The user can execute someone elses plan | 18:52 |
| morganfainberg | ayoung, so the project admin needs to know about the deployer's grand scheme | 18:52 |
| morganfainberg | ayoung, user B wants to boot an image - how does user B do so without knowing the deployment details of OpenStack | 18:53 |
| morganfainberg | s/boot an image/boot an instance/ | 18:53 |
| *** sbfox has joined #openstack-keystone | 18:53 | |
| morganfainberg | how does the user know if glance stores something in swift or not (and if a special token with a special role for that is needed) | 18:54 |
| morganfainberg | ayoung, as long as the story is clear, i don't mind doing it that way (multiple tokens) either | 18:54 |
| morganfainberg | ayoung, but it would need to be "not the end user's responsibility" to know all the tokens. | 18:54 |
| *** dimsum has quit IRC | 18:56 | |
| ayoung | morganfainberg, I think the essential thing to know is that in order to perform a specific workflow, what are the potential operations. | 18:56 |
| ayoung | And allow only those operations | 18:56 |
| ayoung | this is the case for both interactive and non interactive workfloes | 18:57 |
| ayoung | interactive can be done using the same mechanisms as non interactive, which is why I want to solve non-interactive first | 18:57 |
| bknudson | is it only the glance->cinder case that we have to support/ | 18:58 |
| *** zhiyan_ is now known as zhiyan | 18:58 | |
| bknudson | usually it's just nova forwards the token | 18:58 |
| morganfainberg | ayoung, i was going to say exactly the opposite but i agree. | 18:58 |
| bknudson | but cinder wants the requirement that the token is both glance + user | 18:58 |
| bknudson | for glance, there's no need for the token to be both nova + user, the user by themselves should be able to fetch images. | 18:59 |
| morganfainberg | bknudson, yes that was one of the types of examples. | 18:59 |
| bknudson | what's the other examples? | 19:00 |
| *** afazekas has joined #openstack-keystone | 19:00 | |
| bknudson | nova -> neutron, because you don't want the user to mess with networks themselves? | 19:00 |
| bknudson | or should nova use its own token for nova -> neutron? | 19:00 |
| morganfainberg | bknudson, i would say if you don't want the user to mess with networks, but you also don't want the nova user to mess with networks w/o an authorization to do so | 19:01 |
| bknudson | nova's going to need to be able to teardown the network by itself | 19:01 |
| morganfainberg | bknudson, when does nova act on the network w/o authorization (not being snarky, actually curious)? | 19:02 |
| bknudson | morganfainberg: I'm not familiar enough with nova to say... I'd think there'd be a case where nova wants to get rid of some instance it doesn't like. | 19:03 |
| morganfainberg | bknudson, hm. haven't run across that but sure, it could be the case. | 19:03 |
| morganfainberg | bknudson, i'm honestly not familiar enough to know if that is 100% the case | 19:04 |
| morganfainberg | that it doesn't act on the user's behalf (or heat stack etc) always | 19:04 |
| ayoung | I would say then that they user talkingto Neutron should be using a limitedrole for their operation, and the more complex operation should be performed by a more powerful user with a wider role | 19:04 |
| ayoung | snapshot is non-interactive use case, or at least it can be | 19:05 |
| bknudson | y, like a network destroyer role | 19:05 |
| ayoung | I want that role | 19:05 |
| morganfainberg | " - bknudson, destroyer of networks" | 19:05 |
| ayoung | I already have it, I just want the title | 19:05 |
| *** morganfainberg is now known as network_destroye | 19:06 | |
| network_destroye | dang it... too many letters with the _ | 19:06 |
| bknudson | they already made a movie about conan the destroyer | 19:06 |
| *** network_destroye is now known as morganfainberg | 19:06 | |
| *** ayoung is now known as networkDstroyer | 19:07 | |
| *** networkDstroyer is now known as ayoung | 19:07 | |
| morganfainberg | i read that at "networkDtroyer" | 19:07 |
| *** zhiyan is now known as zhiyan_ | 19:07 | |
| ayoung | Conan the Social Network Destroyer | 19:07 |
| morganfainberg | ok anyway | 19:07 |
| morganfainberg | back on topic | 19:07 |
| ayoung | morganfainberg, so the short of it is, you are stepping into a stream I've been trying to swim across for a couple of years now. | 19:08 |
| ayoung | I want to get the audit thing done, and use that to define the operations required by workflows before we build any new mechanisms | 19:09 |
| ayoung | gordc is working on that | 19:09 |
| morganfainberg | ayoung, i don't think we can block everything on that though. or we wont be working on anything until... K. | 19:09 |
| ayoung | morganfainberg, I also think that fetchable policy and per project policy all fall into this same problem space | 19:09 |
| bknudson | what's the composite token idea? it's just an auth with 2 tokens and you get back a composite token? | 19:10 |
| morganfainberg | bknudson, yep. | 19:10 |
| bknudson | doesn't sound hard to implement | 19:10 |
| morganfainberg | bknudson, nope. | 19:10 |
| ayoung | morganfainberg, in the Army we called it "half-assed, full blast, don't know where we're going but we should have been there yesterday." | 19:10 |
| bknudson | then glance needs to use it and cinder needs to support it. | 19:11 |
| morganfainberg | bknudson, correct. | 19:11 |
| morganfainberg | bknudson, well cinder's policy needs to support it | 19:11 |
| morganfainberg | bknudson, no change besides that would be needed | 19:11 |
| ayoung | Its a trap! | 19:11 |
| ayoung | You know how I know? Cuz your statment has a magic word in it. | 19:11 |
| ayoung | Can you guess which one? | 19:11 |
| bknudson | so we need to update policy with a rule for composite tokens or something | 19:12 |
| morganfainberg | bknudson, the composite token would have combined roles. | 19:12 |
| ayoung | We don't need that | 19:12 |
| morganfainberg | bknudson, e.g. glance_service and <user_role> | 19:12 |
| morganfainberg | scoped to <project> | 19:12 |
| ayoung | it could be done with a separate role | 19:12 |
| ayoung | glance gets the "do_somehting_for_someone" role | 19:13 |
| ayoung | onlythe Voltron TOkens get that role | 19:13 |
| bknudson | <token1:<user1, scope1>, token2:<role2:scope2>, roles: [composite]> | 19:14 |
| ayoung | I should call them MegaZord tokens for you young kids. Have you even watched Voltron? | 19:14 |
| bknudson | I did watch voltron | 19:14 |
| morganfainberg | bknudson, sure. | 19:14 |
| bknudson | it was one of the better cartoons | 19:14 |
| topol | I watched Voltron I believe. froma long time ago? | 19:14 |
| morganfainberg | ayoungy, MegaZord, Voltron, <awful knock off>TranzordZ (or similar) | 19:14 |
| bknudson | haven't heard of megazort | 19:14 |
| ayoung | topol, you don't coun't as one of the Young kids. I'm guessing you never watched Power Rangers. | 19:14 |
| bknudson | megazord | 19:14 |
| topol | Im thinking of something else... ultraman perhaps | 19:15 |
| bknudson | voltron was the one where the robot lions all combined into a huge robot with a sword | 19:15 |
| bknudson | they always waited until the end... why not just combine at the beginning. | 19:16 |
| morganfainberg | bknudson that was the good voltron, not to be confused with the car version of it (the bad one) | 19:16 |
| topol | http://en.wikipedia.org/wiki/Ultraman | 19:16 |
| bknudson | have you ever heard of a show where there was a family of rocket ships? | 19:17 |
| morganfainberg | bknudson, but yes that is the idea - obviously with logic to ensure scopes match, usually the service user would have an unscoped token in the design sessions we talked about. | 19:17 |
| bknudson | morganfainberg: so does it need to be general or not? i.e., only support an unscoped service + user | 19:18 |
| ayoung | Voltron ~= MegZord | 19:18 |
| ayoung | the question is "what is the token supposed to be authorized to do" | 19:19 |
| *** daneyon has quit IRC | 19:19 | |
| ayoung | is it blanket authority, or is it limited/ | 19:19 |
| morganfainberg | bknudson, i wanted to make it unscoped only, but hierarcy might dictate you want to combine roles of two projects as long as a common minimum scope can be resolved | 19:19 |
| morganfainberg | roles from two projects that is | 19:20 |
| ayoung | There was the use case: move a resource from project to project, where two users were involved | 19:21 |
| morganfainberg | ayoung, i think that was it. | 19:22 |
| bknudson | I was thinking the rule could be like : "service_token: <glance user ID> and owner: $(user_id)s" | 19:23 |
| bknudson | this would be in cinder policy | 19:23 |
| * ayoung stopped pay attention and is watching/listening to cartoon opening theme songs on YouTube | 19:23 | |
| morganfainberg | bknudson, quick ayoung isn't paying attention, approve something >.> | 19:24 |
| morganfainberg | bknudson, yeah that could absolutely be a policy entry | 19:24 |
| ayoung | morganfainberg, you are asking bknudson to do that? | 19:24 |
| bknudson | http://git.openstack.org/cgit/openstack/cinder/tree/etc/cinder/policy.json | 19:25 |
| bknudson | right, so we're saying the user can't get the volume data... let's say | 19:25 |
| bknudson | "volume:get_volume_metadata": [], | 19:25 |
| bknudson | changes to "volume:get_volume_metadata": "service_token:<glance user ID> and rule:admin_or_owner", | 19:26 |
| bknudson | then the context would have to expose service_token | 19:26 |
| bknudson | and auth_token middleware would have to provide it | 19:26 |
| bknudson | and the token would have to encode it | 19:27 |
| ayoung | so we need to honor "two tokens" not "a token built from two users" | 19:27 |
| bknudson | ayoung: like 2 X-Auth-Token: lines? | 19:28 |
| ayoung | bknudson, each in a separate header? | 19:28 |
| bknudson | ayoung: right, or a separate header for X-Service-Token | 19:28 |
| ayoung | Yep | 19:29 |
| bknudson | we'd really have to compress the tokens! | 19:29 |
| stevemar | dolphm, if you have time, take a look at https://review.openstack.org/#/c/96836/ | 19:29 |
| ayoung | bknudson, each header gets its own limit | 19:29 |
| *** sbfox has quit IRC | 19:29 | |
| morganfainberg | ayoung, no, HTTP: if you issue X-AUTH-TOKEN twice it is presented comma delimited down the line | 19:30 |
| morganfainberg | ayoung, so, it would be X-AUTH-TOKEN: token1,token2 | 19:30 |
| ayoung | morganfainberg, right, so two different headers | 19:30 |
| ayoung | X-AUTH-TOKEN X-SERVICE-TOKEN | 19:30 |
| morganfainberg | oh you're saying make it X-SERVICE-T.. yeah | 19:30 |
| bknudson | what's the advantage to having keystone generate a token from 2 tokens rather than 2 tokens in headers? | 19:31 |
| morganfainberg | bknudson, i think that was spawned from doing the hiearchy resolution and common scope | 19:32 |
| bknudson | would we want to reset the expiration time? | 19:32 |
| morganfainberg | bknudson, i could see 2 headers working just as well | 19:32 |
| bknudson | maybe they don't want to expose their service token to cinder? | 19:33 |
| ayoung | Has the advantage that you don't need to go back to Keystone | 19:33 |
| bknudson | the service token could be short lived. | 19:33 |
| morganfainberg | bknudson, hm. that would be an advantage. and it is signed as valid from keystone - middleware doesn't need to change what it presents to policy enforcement. less change was needed on the enforcement front | 19:34 |
| *** sbfox has joined #openstack-keystone | 19:35 | |
| ayoung | I'm glad we had this little talk | 19:35 |
| *** rodrigods has quit IRC | 19:36 | |
| *** thedodd has quit IRC | 19:39 | |
| topol | when will there be a spec to review? | 19:42 |
| *** radez is now known as radez_g0n3 | 19:42 | |
| topol | :-) | 19:42 |
| morganfainberg | heh | 19:42 |
| *** afazekas has quit IRC | 19:42 | |
| morganfainberg | bknudson, so is there a solid reason to not expose the service token? | 19:42 |
| * topol thats because I need more detail and multiple readings to get my head around this stuff. totally self serving | 19:43 | |
| morganfainberg | bknudson, besides avoiding a change to the middleware. | 19:43 |
| morganfainberg | i do like not having to get keystone involved a second time (or each step of the way) | 19:44 |
| bknudson | morganfainberg: I can't think of anything especially compelling. | 19:44 |
| topol | what days are the keystone hackathon? do we havce those locked down? | 19:45 |
| *** gordc has quit IRC | 19:45 | |
| morganfainberg | topol, http://dolphm.com/openstack-keystone-hackathon-for-juno/ | 19:45 |
| bknudson | topol: did you like the hotel you stayed at last time? | 19:46 |
| topol | yeah, it was great | 19:46 |
| morganfainberg | bknudson, if we end up at geekdom the Valencia is a better place than the courtyard | 19:46 |
| topol | they have an IBM rate | 19:46 |
| bknudson | ldbragst wants to not run into any druggies this time. | 19:46 |
| morganfainberg | topol, ^ | 19:46 |
| topol | yes, but I agree with morganfainberg | 19:47 |
| topol | since at geekdom, we need to find something else | 19:47 |
| morganfainberg | topol, hopefullt dolphm will have an answer re: geekdom or Rackspace castle | 19:47 |
| bknudson | hopefully there's a hotel closer to downtown on the approved hotels list | 19:47 |
| morganfainberg | bknudson, Hotel Valencia is - riverwalk, isn't that close to downtown? | 19:48 |
| bknudson | did anyone stay there last time? | 19:49 |
| topol | bknudson, Im checking if they have an IBM contract rate | 19:49 |
| bknudson | google maps says it's $189! | 19:49 |
| topol | otherwise I think we can get you an exception to be able to stay where everyone else is staying | 19:49 |
| morganfainberg | bknudson, $114 if you use the "Rackspace" codeword | 19:49 |
| morganfainberg | according to dolphm's blog post | 19:50 |
| bknudson | that's such a good deal we have to buy it | 19:50 |
| topol | I thought the codeword was tumbler | 19:50 |
| morganfainberg | i think the courtyard was ... ~100/night last time (ish) | 19:50 |
| morganfainberg | topol, tumblr . com | 19:50 |
| morganfainberg | topol, >.> | 19:51 |
| *** thedodd has joined #openstack-keystone | 19:52 | |
| morganfainberg | bknudson, so nova would pass the bearer token over to glance (still) and glance would use bearer token + it's service token for ... swift - there is no reason nova needs to be involved afaict | 19:54 |
| morganfainberg | bknudson, on the glance -> swift bit | 19:54 |
| bknudson | morganfainberg: right | 19:54 |
| bknudson | so that's just thinking about this specific problem | 19:54 |
| bknudson | I don't know what the other issues are that needed to be solved | 19:54 |
| morganfainberg | bknudson, we'll need to do any hierarchy scope resolution magic in the middleware (nbd) | 19:55 |
| morganfainberg | instead of being able to rely on keystone to figure out common scope. | 19:55 |
| *** dstanek is now known as dstanek_zzz | 19:55 | |
| morganfainberg | bknudson, if we want to support that kind of stuff. | 19:56 |
| morganfainberg | bknudson, ok i think i'm on board with this. - do we want to call it a SERVICE token or use some other nomenclature (cc topol ), and do we want to support only 2 tokens or N tokens | 19:57 |
| morganfainberg | nkinder, ayoung, ^ | 19:57 |
| morganfainberg | dolphm, dstanek_zzz, ^ | 19:57 |
| *** marcoemorais has joined #openstack-keystone | 19:58 | |
| *** zhiyan_ is now known as zhiyan | 19:59 | |
| ayoung | MegaZordToTheMaxToken | 19:59 |
| topol | did we get consensus that $114 really is the special rate? And is this where everyone is staying? If so we should be able to stay there as well. Lots of stuff gets done in the lobby bar | 20:00 |
| ayoung | topol, https://review.openstack.org/#/c/96315/ | 20:02 |
| ayoung | topol, and I think we just decided to not go with that approach | 20:02 |
| ayoung | topol, we tried to collaborate on an Etherpad to get the use cases | 20:03 |
| ayoung | https://etherpad.openstack.org/p/keystone-joint-tokens topol | 20:03 |
| ayoung | morganfainberg, have we released a new Client yet? | 20:04 |
| morganfainberg | ayoung, 0.9.0 is released w/ compression and configurable hashes | 20:04 |
| morganfainberg | ayoung, yesterday | 20:04 |
| bknudson | ok, so one use case is "in glance images are uploaded by nova when it takes a snapshot; images can potentially also be uploaded directly to Glance by end users." | 20:05 |
| bknudson | "allow all users to take snapshots while restricting direct upload with a role" | 20:05 |
| topol | ayoung, so the approach we are going with is in https://review.openstack.org/#/c/96315/ or isnt? | 20:05 |
| *** amerine has quit IRC | 20:05 | |
| *** amerine has joined #openstack-keystone | 20:06 | |
| morganfainberg | topol, i'm reaching out to some folks to make sure there are no pitfalls w/ the dual token headers | 20:06 |
| *** hrybacki has joined #openstack-keystone | 20:06 | |
| ayoung | topol, not as of 15 seconds ago | 20:06 |
| morganfainberg | topol, but i'm on board with it instead of asking keystone to be involved between requests | 20:06 |
| *** stevemar has quit IRC | 20:06 | |
| ayoung | topol, it seems like a very specific mechanism for a limite use case. I think that we don't need it, and we need to look instead to the exsitng mechanisms we have to solve that and a broader class of problems. | 20:07 |
| morganfainberg | ayoung, i'll keep the change-id and replace the spec with the new one [details about the middleware and dualing tokens] | 20:07 |
| ayoung | The rest is commentary, go and study...er read up | 20:07 |
| ayoung | Banjo Tokens! | 20:07 |
| morganfainberg | ayoung, bagpile tokens! | 20:07 |
| morganfainberg | bagpipe* | 20:07 |
| ayoung | Dueling Banjos much more sinister than dueling Bagpipes | 20:08 |
| *** zhiyan is now known as zhiyan_ | 20:08 | |
| *** browne has quit IRC | 20:08 | |
| morganfainberg | ayoung, what about banjos dualing bagpipes? | 20:10 |
| morganfainberg | X-BAGPIPE-TOKEN and X-BANJO-TOKEN | 20:11 |
| bknudson | so one advantage to keystone doing the composing is it'll be a lot simpler to use | 20:17 |
| bknudson | given the client libs that we have today | 20:17 |
| morganfainberg | bknudson, ++ | 20:17 |
| bknudson | although that doesn't seem like the best reason to go with what seems pretty inefficient | 20:18 |
| morganfainberg | i think it'll be about the same level of effort to convince the client libs to put a service token into the request - make it part of the session object. | 20:18 |
| morganfainberg | we front load in service token options in the part of KSC other clients use | 20:18 |
| bknudson | y, if clients are using session then that's a lot easier | 20:18 |
| morganfainberg | bknudson, it's also a carrot for the session object. | 20:18 |
| bknudson | morganfainberg: yes, now we need a stick | 20:19 |
| morganfainberg | bknudson, i think jamielennox|away has been providing some of that with the changes he's been pushing to the other clients | 20:20 |
| *** erecio has quit IRC | 20:24 | |
| *** nkinder has quit IRC | 20:29 | |
| *** ozialien has quit IRC | 20:30 | |
| *** marcoemorais1 has joined #openstack-keystone | 20:34 | |
| *** marcoemorais has quit IRC | 20:34 | |
| *** nkinder has joined #openstack-keystone | 20:42 | |
| *** browne has joined #openstack-keystone | 20:43 | |
| topol | morganfainberg, isn't keystoners who typically update the client libs? | 20:48 |
| topol | i.e. jamielennox taking the lead | 20:49 |
| morganfainberg | topol, well jamielennox|away is doing it. we committed to helping other clients, but we're not 100% on the hook as i understand it | 20:50 |
| *** zhiyan_ is now known as zhiyan | 20:59 | |
| *** praneshp has quit IRC | 20:59 | |
| *** openstackgerrit has quit IRC | 21:01 | |
| *** jaosorior has quit IRC | 21:02 | |
| *** henrynash has quit IRC | 21:05 | |
| *** zhiyan is now known as zhiyan_ | 21:09 | |
| *** dc_ has quit IRC | 21:11 | |
| *** matsuhashi has quit IRC | 21:18 | |
| *** praneshp has joined #openstack-keystone | 21:19 | |
| *** henrynash has joined #openstack-keystone | 21:29 | |
| ayoung | morganfainberg, my goal is to get all of the other clients to use keystoneclient, and all of the services to use keystonemiddleware for middleware and policy management, and then to just solve things for them | 21:40 |
| morganfainberg | ayoung, sure - lofty goal, i like it :) | 21:40 |
| ayoung | and then break things | 21:41 |
| morganfainberg | haha | 21:41 |
| *** hrybacki has quit IRC | 21:42 | |
| *** nkinder has quit IRC | 21:50 | |
| *** david-lyle has quit IRC | 21:50 | |
| *** rodrigods has joined #openstack-keystone | 21:51 | |
| *** david-lyle has joined #openstack-keystone | 21:51 | |
| *** david-lyle has quit IRC | 21:56 | |
| *** zhiyan_ is now known as zhiyan | 22:00 | |
| *** dims has joined #openstack-keystone | 22:02 | |
| *** dims has quit IRC | 22:02 | |
| *** dims has joined #openstack-keystone | 22:04 | |
| *** dims has quit IRC | 22:04 | |
| *** dims has joined #openstack-keystone | 22:07 | |
| *** zhiyan is now known as zhiyan_ | 22:09 | |
| *** dims has quit IRC | 22:12 | |
| *** dims has joined #openstack-keystone | 22:12 | |
| *** hrybacki has joined #openstack-keystone | 22:24 | |
| *** gyee has quit IRC | 22:28 | |
| *** hrybacki has quit IRC | 22:29 | |
| *** openstackgerrit has joined #openstack-keystone | 22:31 | |
| *** openstackgerrit has quit IRC | 22:35 | |
| *** amerine has quit IRC | 22:35 | |
| *** openstackgerrit has joined #openstack-keystone | 22:35 | |
| *** amerine has joined #openstack-keystone | 22:35 | |
| *** topol has quit IRC | 22:36 | |
| *** dims has quit IRC | 22:36 | |
| *** dims has joined #openstack-keystone | 22:37 | |
| *** dims has quit IRC | 22:41 | |
| openstackgerrit | Brant Knudson proposed a change to openstack/keystone: Add v3 curl examples https://review.openstack.org/96973 | 22:44 |
| *** hrybacki has joined #openstack-keystone | 22:44 | |
| *** sbfox has quit IRC | 22:55 | |
| *** henrynash has quit IRC | 22:58 | |
| *** zhiyan_ is now known as zhiyan | 23:01 | |
| *** sbfox has joined #openstack-keystone | 23:02 | |
| *** stevemar has joined #openstack-keystone | 23:06 | |
| *** zhiyan is now known as zhiyan_ | 23:10 | |
| *** rodrigods has quit IRC | 23:11 | |
| *** diegows has quit IRC | 23:13 | |
| *** nsquare has joined #openstack-keystone | 23:14 | |
| *** thedodd has quit IRC | 23:20 | |
| *** dims has joined #openstack-keystone | 23:24 | |
| *** dims has quit IRC | 23:24 | |
| *** dims has joined #openstack-keystone | 23:26 | |
| *** dims has quit IRC | 23:26 | |
| *** stevemar has quit IRC | 23:27 | |
| *** dims has joined #openstack-keystone | 23:28 | |
| *** dims has quit IRC | 23:28 | |
| *** hrybacki has quit IRC | 23:29 | |
| *** dims has joined #openstack-keystone | 23:32 | |
| *** dims has quit IRC | 23:32 | |
| *** rodrigods has joined #openstack-keystone | 23:32 | |
| *** dims has joined #openstack-keystone | 23:38 | |
| *** dims has quit IRC | 23:38 | |
| *** ozialien has joined #openstack-keystone | 23:38 | |
| *** nkinder has joined #openstack-keystone | 23:40 | |
| *** browne has quit IRC | 23:51 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!
