| *** gyee has quit IRC | 00:19 | |
| *** evrardjp has quit IRC | 01:12 | |
| *** Dinesh_Bhor has joined #openstack-keystone | 01:29 | |
| *** sapd1_ has joined #openstack-keystone | 02:04 | |
| *** sapd1 has quit IRC | 02:07 | |
| *** Dinesh_Bhor has quit IRC | 02:22 | |
| openstackgerrit | Vishakha Agarwal proposed openstack/keystone master: Adding test case for MappingEngineTester https://review.openstack.org/603539 | 02:31 |
|---|---|---|
| *** Dinesh_Bhor has joined #openstack-keystone | 02:31 | |
| *** jistr has quit IRC | 03:00 | |
| *** jistr has joined #openstack-keystone | 03:00 | |
| *** BlackDex has quit IRC | 03:01 | |
| *** BlackDex has joined #openstack-keystone | 03:03 | |
| openstackgerrit | Tao Li proposed openstack/keystone master: Use uuidutils instead of uuid.uuid4() https://review.openstack.org/603542 | 03:06 |
| *** Dinesh_Bhor has quit IRC | 03:28 | |
| *** Dinesh_Bhor has joined #openstack-keystone | 03:34 | |
| *** Dinesh_Bhor has quit IRC | 03:42 | |
| *** prashkre has joined #openstack-keystone | 03:45 | |
| *** prashkre has quit IRC | 03:51 | |
| vishakha | wxy-xiyuan: Hello. Can you pl review this test caes https://review.openstack.org/#/c/603539/ | 04:10 |
| *** jaosorior_ is now known as jaosorior | 04:13 | |
| vishakha | cmurphy: Pl have a look on https://review.openstack.org/#/c/589378/. Need one more +2 | 04:14 |
| *** Dinesh_Bhor has joined #openstack-keystone | 04:32 | |
| *** shyamb has joined #openstack-keystone | 05:24 | |
| *** shyamb has quit IRC | 05:29 | |
| *** rcernin has quit IRC | 05:30 | |
| *** rcernin has joined #openstack-keystone | 05:30 | |
| *** shyamb has joined #openstack-keystone | 05:50 | |
| *** rcernin_ has joined #openstack-keystone | 06:04 | |
| *** rcernin has quit IRC | 06:06 | |
| *** rcernin has joined #openstack-keystone | 06:34 | |
| *** rcernin_ has quit IRC | 06:36 | |
| *** deepak_mourya_ has quit IRC | 06:40 | |
| openstackgerrit | Colleen Murphy proposed openstack/keystone master: Convert legacy functional jobs to Zuul-v3-native https://review.openstack.org/602452 | 07:01 |
| *** shyamb has quit IRC | 07:04 | |
| *** rcernin has quit IRC | 07:06 | |
| *** Dinesh_Bhor has quit IRC | 07:09 | |
| *** shyamb has joined #openstack-keystone | 07:10 | |
| *** shyamb has quit IRC | 07:17 | |
| *** hoonetorg has quit IRC | 07:17 | |
| *** sonuk has joined #openstack-keystone | 07:18 | |
| *** shyamb has joined #openstack-keystone | 07:27 | |
| *** hoonetorg has joined #openstack-keystone | 07:30 | |
| *** Dinesh_Bhor has joined #openstack-keystone | 07:36 | |
| *** jamiec has quit IRC | 07:38 | |
| *** blake has joined #openstack-keystone | 07:38 | |
| *** jamiec has joined #openstack-keystone | 07:43 | |
| *** shyamb has quit IRC | 07:45 | |
| openstackgerrit | Tao Li proposed openstack/keystone master: Use uuidutils instead of uuid.uuid4() https://review.openstack.org/603542 | 08:01 |
| *** Emine has joined #openstack-keystone | 08:06 | |
| *** blake has quit IRC | 08:32 | |
| *** shyamb has joined #openstack-keystone | 08:38 | |
| *** shyamb has quit IRC | 08:43 | |
| *** shyamb has joined #openstack-keystone | 08:43 | |
| *** markvoelker has quit IRC | 09:25 | |
| *** shyamb has quit IRC | 09:29 | |
| *** shyamb has joined #openstack-keystone | 09:30 | |
| *** shyamb has quit IRC | 09:41 | |
| *** shyamb has joined #openstack-keystone | 09:45 | |
| *** Dinesh_Bhor has quit IRC | 09:49 | |
| *** Dinesh_Bhor has joined #openstack-keystone | 09:52 | |
| *** shyamb has quit IRC | 09:57 | |
| *** shyamb has joined #openstack-keystone | 10:00 | |
| *** Dinesh_Bhor has quit IRC | 10:04 | |
| *** shyamb has quit IRC | 10:05 | |
| *** markvoelker has joined #openstack-keystone | 10:30 | |
| *** shyamb has joined #openstack-keystone | 10:33 | |
| *** Dinesh_Bhor has joined #openstack-keystone | 10:37 | |
| *** Dinesh_Bhor has quit IRC | 10:39 | |
| *** pooja_jadhav has quit IRC | 10:40 | |
| *** shyamb has quit IRC | 10:49 | |
| *** shyamb has joined #openstack-keystone | 10:49 | |
| *** pooja_jadhav has joined #openstack-keystone | 10:56 | |
| *** pooja-jadhav has joined #openstack-keystone | 10:57 | |
| *** markvoelker has quit IRC | 11:00 | |
| *** shyamb has quit IRC | 11:06 | |
| *** imacdonn has quit IRC | 11:19 | |
| *** imacdonn has joined #openstack-keystone | 11:20 | |
| openstackgerrit | Juan Antonio Osorio Robles proposed openstack/oslo.policy master: Implement base for pluggable policy drivers https://review.openstack.org/577807 | 11:38 |
| *** raildo has joined #openstack-keystone | 11:56 | |
| *** markvoelker has joined #openstack-keystone | 11:57 | |
| *** shyamb has joined #openstack-keystone | 12:15 | |
| *** pgaxatte has joined #openstack-keystone | 12:30 | |
| pgaxatte | hello | 12:30 |
| *** markvoelker has quit IRC | 12:31 | |
| pgaxatte | I have an issue with keystone middleware in rocky | 12:32 |
| pgaxatte | I'm trying mistral and I use a memcache server | 12:32 |
| pgaxatte | when installing mistral in a venv, I noticed I don't have python-memcached installed which causes an ImportError in keystonemiddleware | 12:33 |
| pgaxatte | here precisely: https://github.com/openstack/keystonemiddleware/blob/stable/rocky/keystonemiddleware/auth_token/_cache.py#L77 | 12:34 |
| pgaxatte | python-memcached seems only required for the tests (according to the METADATA file of the egg) | 12:35 |
| *** kukacz_ is now known as kukacz | 13:00 | |
| openstackgerrit | Colleen Murphy proposed openstack/keystone master: Convert legacy functional jobs to Zuul-v3-native https://review.openstack.org/602452 | 13:03 |
| mbeierl | Hey, knikolla, wondering if you've got any time to help with the keystone/shibboleth federation. I got past the PAOS response error, but am still stuck with a fatal profile exception | 13:03 |
| openstackgerrit | Colleen Murphy proposed openstack/keystone master: Convert legacy functional jobs to Zuul-v3-native https://review.openstack.org/602452 | 13:15 |
| mordred | cmurphy: tox_envlist: all ? | 13:26 |
| mordred | cmurphy: would tox_envlist: functional be a better choice there? | 13:27 |
| cmurphy | mordred: hi do you want to help me | 13:27 |
| cmurphy | i'm following https://docs.openstack.org/devstack/latest/zuul_ci_jobs_migration.html | 13:27 |
| mordred | OH - | 13:28 |
| mordred | that's going to run tox in the tempest repo | 13:28 |
| mordred | *duh* | 13:28 |
| * mordred isn't always smart | 13:28 | |
| cmurphy | heh okay | 13:29 |
| cmurphy | because without it this was happening http://logs.openstack.org/52/602452/3/check/keystone-dsvm-functional/5b30bc0/job-output.txt.gz#_2018-09-18_15_11_26_153936 | 13:29 |
| mordred | yeah. makes totally more sense now | 13:29 |
| cmurphy | i still don't know what i'm doing though, just trying to poke it till it works | 13:30 |
| lbragstad | o/ | 13:36 |
| cmurphy | lbragstad: do you have advice for pgaxatte ^ i don't remember where we landed on that | 13:37 |
| lbragstad | on making python-memcache a hard requirement? | 13:38 |
| cmurphy | yeah | 13:38 |
| lbragstad | i don't remember a clear outcome :( | 13:38 |
| lbragstad | but... | 13:38 |
| lbragstad | I think my initial knee-jerk reaction is to just include it officially | 13:39 |
| lbragstad | (i thought something with memcache was python three related, though) | 13:39 |
| aning | Hi guys, is application credential stable in queens release? | 13:39 |
| lbragstad | aning it is | 13:42 |
| lbragstad | queens was the initial release of application credentials and they were marked as stable from the beginning | 13:42 |
| aning | Thx. | 13:42 |
| aning | What other openstack services support application credentials if any? | 13:43 |
| aning | Is there any information about that? | 13:43 |
| cmurphy | application credentials are mostly meant to be used by end users, but any openstack service that uses keystonemiddleware automatically supports using application credentials for service user authentication | 13:47 |
| aning | cmurphy: but do we have to configure the [keystone_authtoken] section of the openstack service in order for it to use application credential? | 13:49 |
| cmurphy | aning: yes, there's an example here https://docs.openstack.org/keystone/latest/user/application_credentials.html#using-application-credentials | 13:50 |
| aning | Is it that once the service is configured with application credential, the service just natively and automatically use it? | 13:51 |
| aning | cmurphy: yep, I'm readning that document | 13:52 |
| cmurphy | aning: after creating the application credential and configuring [keystone_authtoken] like that it should just work | 13:52 |
| aning | cmurphy: ok ... I'm thinking does the service need some (extra) logic to read, understand, and send the application credential to keystone for authentication? | 13:54 |
| aning | If this is all handled by keystonemiddleware, I could understand the serive doesn't need any change ... | 13:55 |
| cmurphy | aning: no, the service shouldn't need to do anything special, it's all handled in keystonemiddleware and keystoneauth | 13:55 |
| aning | cmurphy: yeah, got it. | 13:55 |
| aning | cmurphy: btw, which table is the application credential hash stored? | 13:57 |
| aning | credential? | 13:58 |
| cmurphy | aning: 'application_credential' | 13:58 |
| cmurphy | 'credential' is for something else | 13:59 |
| aning | cmurphy: so a new table is introdued. | 14:00 |
| cmurphy | aning: yes | 14:00 |
| aning | cmurphy: thx | 14:01 |
| cmurphy | aning: np | 14:02 |
| *** shyamb has quit IRC | 14:03 | |
| lbragstad | that reminds me - i'd like to try and work on an example for using app creds for a single support user | 14:11 |
| lbragstad | in case anyone wants to double check my work - https://review.openstack.org/#/c/603822/ | 14:46 |
| lbragstad | ^ those are very similar deadlines to what we used for Queens | 14:46 |
| *** aning_ has joined #openstack-keystone | 14:51 | |
| *** marvin_mhg has quit IRC | 14:53 | |
| *** aning has quit IRC | 14:54 | |
| lbragstad | hrybacki the audit that gmann did here here is kind of similar to what you were doing (minus adding the granularity) https://review.openstack.org/#/c/547850/ | 14:54 |
| *** aning has joined #openstack-keystone | 14:55 | |
| * hrybacki looks | 14:57 | |
| *** aning_ has quit IRC | 14:57 | |
| hrybacki | lbragstad: looking at specs on gerrit can be the worst. I'll review that this afternoon | 14:58 |
| lbragstad | yep - no problem | 14:59 |
| pgaxatte | cmurphy, lbragstad: reading keystonemiddleware code I don't understand the comment https://github.com/openstack/keystonemiddleware/blob/master/keystonemiddleware/auth_token/_cache.py#L92 | 15:06 |
| pgaxatte | it says to rely on oslo_cache to lazily import memcache | 15:06 |
| pgaxatte | but having oslo.cache also in my virtualenv has not added python-memcached as a dependency | 15:07 |
| pgaxatte | also, as soon as there is an "import blah" in the code, shouldn't it make the package blah a hard dependency? | 15:07 |
| cmurphy | kmalloc: want to comment on that ^ | 15:08 |
| *** Emine has quit IRC | 15:10 | |
| hrybacki | kmalloc: I'm looking at the API ref to but can't find anything the HEAD endpoints for the v3/projects/<id>/tags and ve/projects/<id>/tags/<value> -- should they respond in the same way as a GET in this case? | 15:12 |
| hrybacki | https://developer.openstack.org/api-ref/identity/v3/#create-project | 15:12 |
| kmalloc | hrybacki: head uses get unless explicitly defined. | 15:12 |
| kmalloc | If the behavior of head is fundamentally different than get (some of our APIs) then implement head specifically | 15:13 |
| kmalloc | cmurphy: answering now | 15:13 |
| hrybacki | kmalloc++ thanks for confirming. So how are we handling that with flask? /me keeps digging | 15:13 |
| kmalloc | hrybacki: just implement head when needed. | 15:14 |
| hrybacki | ah, 'magic' | 15:14 |
| kmalloc | hrybacki: otherwise just let get work how it is supposed to (same behavior between head and get) | 15:14 |
| kmalloc | hrybacki: flask automatically removes content on head if it falls through to get (flask restful) | 15:15 |
| kmalloc | pgaxatte: so, in our code, most of the time you can use different options on the backend. If you never use memcache, there is no reason to install it. | 15:17 |
| kmalloc | pgaxatte: so, it is not a hard dep. Many folks use other options/no caching. | 15:17 |
| kmalloc | pgaxatte: if it was pymemcache vs python-memcached we might make it a hard dep. | 15:18 |
| kmalloc | cmurphy: ^ :) | 15:18 |
| cmurphy | kmalloc: ty | 15:18 |
| pgaxatte | kmalloc: I understand but this makes mistral, in my case, break horribly | 15:18 |
| kmalloc | pgaxatte: explicitly add python-memcached in Mistral or just know you need to install it. | 15:19 |
| pgaxatte | kmalloc: so I should install python-memcached separately as a dependency of my architecture | 15:19 |
| kmalloc | Yeah | 15:19 |
| pgaxatte | ok | 15:19 |
| kmalloc | I have moving to pymemcache on my backlog | 15:19 |
| kmalloc | It is pretty far down my list right now (sorry) | 15:19 |
| kmalloc | I hope I can do it in stien, but am not sure. | 15:20 |
| pgaxatte | should the "import memcache" at least by protected in case of ImportError? | 15:20 |
| pgaxatte | because in my case, mistral throws a 500 and no message, no log, nothing | 15:21 |
| pgaxatte | I took me some time to find the root cause with pdb :D | 15:21 |
| kmalloc | Not sure, can you point me at where this is happening? I want to know the context before answering. | 15:27 |
| pgaxatte | kmalloc: I need to dig back in mistral to find the exact place this is happening | 15:28 |
| kmalloc | Because it might indicate Mistral needs it independently. | 15:28 |
| cmurphy | _MemcacheClientPool should only be instantiated if you have memcached_servers set in keystonemiddleware https://github.com/openstack/keystonemiddleware/blob/master/keystonemiddleware/auth_token/_cache.py#L148 so you have to opt into it and you're assumed to have installed the dependencies if you do that | 15:29 |
| kmalloc | cmurphy: ahh thats it. | 15:30 |
| *** gyee has joined #openstack-keystone | 15:37 | |
| *** pcaruana has joined #openstack-keystone | 15:47 | |
| pgaxatte | kmalloc: ok so I cannot pinpoint the start of the problem in mistral but the middleware is added here: https://github.com/openstack/mistral/blob/master/mistral/api/access_control.py#L39 | 15:57 |
| pgaxatte | this might not be helpful :D | 15:58 |
| pgaxatte | the problem occurs in the process_request of AuthProtocol | 15:58 |
| kmalloc | Yeah, it's a config bit, for now, install python-memcached as part of the architecture | 15:59 |
| pgaxatte | kmalloc: alright, i'll do that | 15:59 |
| pgaxatte | thanks ;) | 15:59 |
| openstackgerrit | Merged openstack/keystone-tempest-plugin master: Import another job from project-config https://review.openstack.org/603281 | 16:20 |
| *** pcaruana has quit IRC | 16:27 | |
| tobias-urdin | heads up on broken keystone q->r upgrade path | 16:28 |
| tobias-urdin | https://bugs.launchpad.net/keystone/+bug/1793347 | 16:28 |
| openstack | Launchpad bug 1793347 in OpenStack Identity (keystone) "keystone upgrade fails q->r oslo.log requirement to low" [Undecided,New] | 16:28 |
| openstackgerrit | Merged openstack/keystone master: Use templates for cover and lower-constraints https://review.openstack.org/600690 | 16:44 |
| aning | cmurphy: I'm reading your blog at http://www.gazlene.net/demystifying-keystone-federation.html. Looks like queens support both SAML2.0 WEBSSO and ECP. The setup with keystone and horizon is based on WEBSSO, and the k2k setup is based on ECP. Do I understand right? | 17:04 |
| tobias-urdin | lbragstad: ping on launchpad link above fyi | 17:04 |
| gagehugo | tobias-urdin lbragstad likely https://review.openstack.org/#/c/558901/ didn't get added until 3.37.0 | 17:34 |
| lbragstad | tobias-urdin there is a patch up for review https://review.openstack.org/#/c/599447/ | 17:41 |
| cmurphy | aning: yes, mostly; keystone as a service provider can work with both websso and ecp, and using horizon depends on websso. when keystone is in a k2k setup it doesn't have websso support, so horizon relies on a kind of modified ecp flow on the backend | 18:16 |
| aning | cmurphy: Can I setup a keystone as SP with an external Idp (instead of keystone) and use ECP for the user agent to authenticate itself? | 18:22 |
| aning | cmurphy: the reason is that we may have an application (based on keystone client) that will use federated authentication. | 18:24 |
| gagehugo | lbragstad can we not bump oslo.log in rocky? | 18:25 |
| lbragstad | gagehugo sounds like it violates stable policy | 18:25 |
| lbragstad | gagehugo we need to check with tonyb | 18:25 |
| lbragstad | sounds like he wants to better understand why it failed | 18:26 |
| cmurphy | aning: yes that is possible, it relies on the IdP supporting ECP (not all of them do) and the apache SP may need to have ECP turned on (shibboleth has it turned off by default) | 18:26 |
| cmurphy | lbragstad: i think tonyb is on vacation for a couple of weeks | 18:27 |
| lbragstad | ack | 18:27 |
| lbragstad | thanks cmurphy | 18:27 |
| gagehugo | ah | 18:28 |
| *** AJaeger has left #openstack-keystone | 18:28 | |
| aning | cmurphy: so still relay on the apache SP mod (such as shiboketh) | 18:29 |
| cmurphy | aning: yes | 18:31 |
| aning | cmurphy: the user agent application, does keystoneclient support ECP already? | 18:32 |
| aning | cmurphy: since the user agent will talk to shiboleth mod in SAML ECP ... | 18:33 |
| cmurphy | aning: keystoneauth supports it which means keystoneclient and openstackclient also support it | 18:34 |
| aning | cmurphy: cool. I'll check if there are APIs for ECP Response ... | 18:34 |
| aning | cmurphy: the support should be in form of APIs right? | 18:35 |
| aning | cmurphy: or maybe not | 18:38 |
| cmurphy | aning: hmm not sure what you mean by in the form of APIs, if you pass it the right credentials and parameters it will get you a token which gives you normal access to all the openstack apis | 18:40 |
| aning | cmurphy: ok IC. same idea, it;s all handled in the background by keystoneauth | 18:41 |
| cmurphy | right | 18:42 |
| aning | Thx | 18:42 |
| *** jdennis has quit IRC | 18:51 | |
| *** ayoung has joined #openstack-keystone | 18:53 | |
| ayoung | hrybacki, kmalloc in a customer presentation at the moment. Not sure if it will go long. Have to wait til its over to switch to talking with you | 18:56 |
| *** BlackDex has quit IRC | 18:57 | |
| kmalloc | All good, just ping when done. | 18:57 |
| hrybacki | ayoung: ack | 18:57 |
| kmalloc | I am not on the thing yet | 18:57 |
| *** BlackDex has joined #openstack-keystone | 18:58 | |
| hrybacki | ayoung: kmalloc I've got a few hurricane victims that are coming over to get settled -- might not be until after the mtg -- but will have to drop to help them for a bit | 18:59 |
| hrybacki | kmalloc: wanna join now? I have some questions I can field off of you in the meantime | 18:59 |
| kmalloc | hrybacki: yeah joining now | 19:01 |
| kmalloc | btw, no mic/headset so dealing with laptop mic (gross) | 19:02 |
| lbragstad | cmurphy i ended up just putting most of the feedback for documentation improvements into a single report - https://bugs.launchpad.net/keystone/+bug/1793374 | 19:32 |
| openstack | Launchpad bug 1793374 in OpenStack Identity (keystone) "Federated documentations lacks a concise introduction" [Low,Triaged] | 19:32 |
| cmurphy | lbragstad: okay | 19:33 |
| lbragstad | also - i was wrong about the document that jdennis authored | 19:33 |
| cmurphy | lbragstad: i'm just gonna assign it to myself | 19:34 |
| lbragstad | i thought he wrote something for federation, but it was actually for PCI-DSS | 19:34 |
| lbragstad | https://github.com/jdennis/documentation/blob/master/openstack/keystone/pci-dss-notes.rst | 19:34 |
| cmurphy | lbragstad: i thought he wrote all the deep-dive mod_auth_mellon docs | 19:35 |
| lbragstad | are those already in our docs? | 19:35 |
| cmurphy | lbragstad: no, they're in mod_auth_mellon's docs https://github.com/Uninett/mod_auth_mellon/commit/ee97812b978cf1cf99bd787d90cf2ace457f475c#diff-670e4c737aee3f2353337e380af89f82 | 19:36 |
| lbragstad | oh - interesting | 19:36 |
| lbragstad | ... | 19:37 |
| lbragstad | damn | 19:37 |
| lbragstad | i wonder if we should just point to that if we don't already | 19:39 |
| cmurphy | probably | 19:40 |
| cmurphy | i think the last time i touched our docs all that mellon had was the github readme | 19:40 |
| lbragstad | =/ | 19:40 |
| lbragstad | i remember sitting down with asettle, dolphm, and dstanek about 3 years ago, and we were talking pretty much the same thing as whats in https://bugs.launchpad.net/keystone/+bug/1793374 | 19:41 |
| openstack | Launchpad bug 1793374 in OpenStack Identity (keystone) "Federated documentations lacks a concise introduction" [Low,Triaged] - Assigned to Colleen Murphy (krinkle) | 19:41 |
| aning | cmurphy: lbragstad: a deep-dive document would be great! | 19:42 |
| cmurphy | aning: check out the mod_auth_mellon user guide https://github.com/Uninett/mod_auth_mellon/blob/master/doc/user_guide/mellon_user_guide.adoc it gives a ton of useful background on SAML even if you're not using the mellon SP | 19:45 |
| aning | cmurphy: thx | 19:46 |
| openstackgerrit | Gage Hugo proposed openstack/keystone master: [WIP] Add functional testing gate https://review.openstack.org/531014 | 20:33 |
| openstackgerrit | Gage Hugo proposed openstack/keystone master: [WIP] Add functional testing gate https://review.openstack.org/531014 | 20:36 |
| openstackgerrit | Merged openstack/keystone master: Remove unused revoke_by_user_and_project https://review.openstack.org/602216 | 20:39 |
| *** dklyle has quit IRC | 20:47 | |
| *** raildo has quit IRC | 20:54 | |
| *** dklyle has joined #openstack-keystone | 21:42 | |
| adriant | lbragstad: regarding all the policy and role work, is there an option to sneak an 'auth-only' role into the mix? A role that lets you do pretty much nothing other than maybe change your own password, and exist within a project scope (but with no permissions to any resources in it). | 21:45 |
| lbragstad | we actually don't protect authentication or password changes with policies | 21:46 |
| lbragstad | (how do you verify the roles a user has at authentication time) | 21:46 |
| adriant | lbragstad: sorry, just had to run to morning standup | 21:57 |
| adriant | my context is... | 21:57 |
| adriant | right now we have a lot of default policies in openstack. They amount to "user is authed" | 21:58 |
| adriant | which makes it really hard to go through and actually make roles that aren't affected by these default policies | 21:58 |
| adriant | if ALL the policy rules required a role, unless explicitly meant not to, then we can make roles that by default are no-ops | 21:59 |
| adriant | this is useful in a few ways for me, but one... is Swift | 21:59 |
| adriant | Swift ACLs kind of conflict with Keystone roles, and to really use swift ACLs properly with users, or auth creds, you need a user that is auth'd but can't do anything so the ACLs can be assigned to them with the knowledge they can only do Swift things | 22:00 |
| adriant | So a role that explicitly lets you do almost nothing, but can be used to give a user scope within a project, suddenly solves a lot of the Swift ACLs vs Keystone roles issues | 22:02 |
| lbragstad | does swift fall through if there are roles in the token used to access it's API? | 22:03 |
| adriant | yes | 22:03 |
| lbragstad | but it needs a project... | 22:03 |
| adriant | well no, it needs an auth'd user | 22:04 |
| lbragstad | so - this might be a naive question, but can't you use an unscoped token? | 22:04 |
| adriant | but I don't know if an unscoped token is quite enough, but you can do ACLs per project so a no-op role would be useful for limiting that | 22:04 |
| adriant | https://docs.openstack.org/swift/latest/overview_acl.html#keystone-auth-acl-elements | 22:04 |
| adriant | "A token for the user (scoped to any project)" | 22:05 |
| *** jdennis has joined #openstack-keystone | 22:05 | |
| adriant | so looks like not, but I've never actually tested it | 22:05 |
| lbragstad | so it does require a project... | 22:05 |
| adriant | basically, if "member" lets you access all the containers in a project in Swift, then the ACLs are bypasses | 22:05 |
| lbragstad | and that's not what you want? | 22:06 |
| lbragstad | because you want to do more granular things with the ACLs? | 22:06 |
| adriant | yes | 22:06 |
| adriant | I could assign member in a different project... | 22:06 |
| lbragstad | ok | 22:06 |
| adriant | but that's awful | 22:06 |
| lbragstad | so - we can't actually use policies for protecting authenticate | 22:07 |
| lbragstad | authenticate doesn't actually have a policy | 22:07 |
| adriant | that's not what I need though | 22:07 |
| lbragstad | so... what you could do | 22:08 |
| adriant | we want a user to be auth'd, just don't do the default policy stuff which is 'an authed user' and instead make all the policies actually require explicit roles | 22:08 |
| adriant | we've kind of done that internally, but finding and actually cleaning up all those empty default policies is annoying with some of the older policy files :( | 22:09 |
| adriant | like, we use the member role as an explicit requirement for most API calls. | 22:09 |
| lbragstad | so - if you have a role called 'noop' and you give it to me on project foo, that doesn't work? | 22:09 |
| adriant | it does in our case | 22:10 |
| adriant | and with the upstream policy work you're doing with the new default roles, (read/write?) you are making most API calls explicit? | 22:10 |
| adriant | the policy I mean | 22:10 |
| lbragstad | we're going to provide new defaults, yes | 22:11 |
| lbragstad | and fit each API into one of three camps | 22:11 |
| lbragstad | so - read operations will need the 'reader' role at the very least | 22:11 |
| lbragstad | (e.g. getting or listing resources) | 22:11 |
| adriant | cool, I just wanted you to be aware of the usefulness as part of that work of an noop type role | 22:11 |
| adriant | or well, any new role by default would be a noop role | 22:12 |
| lbragstad | unless they are implied | 22:12 |
| lbragstad | which they are in our case | 22:12 |
| lbragstad | admin implies member which implies reader | 22:12 |
| lbragstad | so if you have the member role on a project, you get the ability to perform list operations | 22:13 |
| adriant | and are you making 'reader' explicitly defined in the new default policy as a requirement? | 22:14 |
| adriant | e.g. for a list "role:read" | 22:15 |
| adriant | which then the implied stuff handles? | 22:15 |
| *** jdennis has quit IRC | 22:15 | |
| lbragstad | correct | 22:15 |
| lbragstad | it seemed like an appropriate compromise | 22:15 |
| lbragstad | instead of defining something like "identity:list_users": "role:admin OR role:member OR role:reader" | 22:16 |
| lbragstad | instead we just do "identity:list_users": "role:reader" | 22:16 |
| adriant | fantastic, then yes, hopefully by the end of that work, the default policies will allow an easy noop still role since there should be far far less empty policies | 22:16 |
| lbragstad | i guess i'm still a little lost on how the empty policies break that | 22:16 |
| adriant | "identity:list_users": "" < any auth'd user can call this API | 22:17 |
| adriant | vs "identity:list_users": "role:reader" where it must have a specific role | 22:18 |
| lbragstad | oh! | 22:18 |
| adriant | I know a lot of the various API just assume if you exist as a user in project scope, you can call APIs for resources on that project | 22:18 |
| lbragstad | ok.. | 22:18 |
| lbragstad | so you've gone through and actually made those changes by overriding the policies so that I can't access something i'm not supposed to because I have a role called "swift-noop" | 22:19 |
| adriant | yes | 22:19 |
| lbragstad | damn... | 22:19 |
| lbragstad | ok | 22:19 |
| lbragstad | from a keystone perspective, there shouldn't be many empty policies i don't think? | 22:20 |
| adriant | we're having to do that because all the empty rules are kind of too powerful still | 22:20 |
| adriant | nah, Keystone is pretty good | 22:20 |
| adriant | it's all the other services | 22:20 |
| adriant | nova was pretty bad | 22:20 |
| adriant | so many empty rules | 22:20 |
| adriant | But it sounded like you were driving part of the cross project effort | 22:20 |
| lbragstad | yeah... | 22:20 |
| lbragstad | it's a long ways away | 22:20 |
| lbragstad | we need to build out the system-scope and new default roles in keystone so that other services at least have a reference to follow | 22:21 |
| adriant | so I thought you should be aware of the pain we're going through internally trying to fill all the blank rules. | 22:21 |
| lbragstad | after that we might try and make it a community goal | 22:21 |
| adriant | ok cool | 22:21 |
| lbragstad | if anyone from catalyst is interested in working on that upstream or pushing it forward, just ask... | 22:23 |
| lbragstad | we should be able to break thing apart into bite-sized pieces | 22:23 |
| adriant | I'd gladly raise my hand, but I have so many things on my plate right now | 22:23 |
| adriant | But I'll probably raise my hand anyway closer to the time | 22:24 |
| lbragstad | i hear ya | 22:24 |
| adriant | I've had a post-it on my wall for ages now to try and get this policy work done on our cloud so we can safely do an 'auth-only' role, and part of that was going to be review all our policies and play with patrole | 22:25 |
| adriant | all I want the role to do is be able to auth, update own password, and setup MFA for self, but first I need to make sure we've not left any other policies open :( | 22:26 |
| adriant | it's a pain | 22:26 |
| adriant | lbragstad, kmalloc: I'll try and have a new auth-receipts patch up soonish. | 22:28 |
| adriant | I want to try and get a large part of the MFA work done before the summit | 22:28 |
| lbragstad | ok | 22:29 |
| lbragstad | yeah - i guess if you were to do a really limited role you could create something like 'auth-only' | 22:30 |
| lbragstad | and then have reader imply it | 22:30 |
| lbragstad | then if there are any APIs that you want them to have access to (which I'm assuming wouldn't be many) you'd just override those to be role:auth-only instead or role:reader | 22:31 |
| adriant | pretty much. | 22:32 |
| *** jdennis has joined #openstack-keystone | 22:33 | |
| adriant | I've yet to play with implied roles much on our cloud, but will be doing something soon for resellers | 22:33 |
| lbragstad | it's pretty straight forward... | 22:33 |
| lbragstad | if you have a role assignment that implies another role, we just expand the token reference to include both during token validaiton | 22:34 |
| lbragstad | validation* | 22:34 |
| adriant | we have a bunch of APIs we can't have resellers seeing so I'll have reseller_member imply member, and then the policy rule will read "role:member AND NOT role:reseller_member" | 22:34 |
| lbragstad | mmmm | 22:34 |
| lbragstad | what kind of APIs can't resellers see? | 22:34 |
| lbragstad | like deployment-specific stuff? | 22:34 |
| adriant | account admin and billing ones | 22:34 |
| lbragstad | ah | 22:34 |
| lbragstad | did you happen to see my patch for the credentials work? | 22:35 |
| adriant | no? | 22:35 |
| adriant | we talking app creds or 'credentials' ? | 22:35 |
| lbragstad | "credentials" | 22:36 |
| lbragstad | https://review.openstack.org/#/c/594547/ | 22:36 |
| lbragstad | it is failing two tests... | 22:36 |
| cmurphy | we are the best at naming | 22:36 |
| lbragstad | ^ fact | 22:36 |
| kmalloc | ... | 22:36 |
| kmalloc | i... | 22:36 |
| kmalloc | sigh | 22:36 |
| cmurphy | :P | 22:36 |
| adriant | naming things is hard :P | 22:36 |
| * kmalloc kills "credentials" with something sharp | 22:36 | |
| kmalloc | there. | 22:37 |
| kmalloc | fixed. | 22:37 |
| kmalloc | >.> | 22:37 |
| kmalloc | <.< | 22:37 |
| adriant | "secrets" ? | 22:37 |
| lbragstad | i mean... we *did* renaming tenants to projects.... | 22:37 |
| adriant | just rename them to secrets, because that is closer to what they are | 22:37 |
| kmalloc | "no really, this stuff should have been in barbican.. but we made some bad design decisions" | 22:37 |
| adriant | although barbican might complain | 22:37 |
| lbragstad | it's like we get bonus points if we overload the term, too | 22:37 |
| kmalloc | i think that is the official name | 22:37 |
| adriant | self service elements to the credentials APIs would be good, but I'm willing to bet you people will end up using it, and the MFA rules directly and locking themselves out of their own users ;) | 22:39 |
| lbragstad | but yeah - that patch is a WIP for trying in make the credentials API more self-serviceable | 22:39 |
| lbragstad | we want to try and that applied consistently across stein | 22:39 |
| lbragstad | which will mean two things | 22:39 |
| lbragstad | 1.) scope will be honored better than it is today | 22:39 |
| adriant | I say do it, but I'll write some sanity checking APIs in Adjutant for MFA management most likely | 22:39 |
| lbragstad | 2.) policies will incorporate the new default roles | 22:40 |
| lbragstad | that would make things easier for adjutant, right? | 22:40 |
| lbragstad | because you can just consume what we've done instead of having to write a layer on top that handles that? | 22:40 |
| adriant | I'd still use the admin level powers really unless I reuse the user token | 22:40 |
| adriant | potentially yeah | 22:41 |
| *** hoonetorg has quit IRC | 22:41 | |
| adriant | I need to read through the patch! | 22:41 |
| lbragstad | yeah - i'd be curious to know if you have feedback | 22:41 |
| lbragstad | since it sounds like adjutant has worked around a lot of this stuff | 22:41 |
| adriant | right now we do MFA a little differently since we aren't yet touching auth rules, hence why the MFA code isn't in core Adjutant | 22:42 |
| adriant | but the eventual logic will be: "ask for a totp secret (which adjutant creates as a credential in keystone)" > "pass back a passcode" > "Adjutant validates passcode and adds auth rules for totp to user" | 22:43 |
| adriant | which doesn't exactly need a self service API since the user never touches credentials directly | 22:43 |
| adriant | or auth rules | 22:43 |
| adriant | and turning off totp is pretty much: "pass back a passcode" > "Adjutant validates passcode and removes auth rules for totp from user" | 22:44 |
| adriant | so again, user can't touch credentials directly | 22:44 |
| *** rcernin has joined #openstack-keystone | 22:44 | |
| lbragstad | gotcha | 22:45 |
| adriant | since that bypasses the need for them to prove they have the totp secret twice (once for auth, again for removal) | 22:45 |
| adriant | but... without Adjutant around, self service is useful, but prone to accidentally doing things a little wrong without hand holding | 22:46 |
| lbragstad | sure | 22:46 |
| adriant | I can always as part of the Adjutant setup docs include: "update these keystone policies to turn off self service" | 22:46 |
| lbragstad | we do some interesting stuff in the policies to make sure the user can do that stuff, which might be interesting if you try to shut it off | 22:47 |
| lbragstad | for example - how these are changing https://review.openstack.org/#/c/594547/10/keystone/common/policies/credential.py | 22:48 |
| lbragstad | and how we are modifying the business logic of the API to account for it https://review.openstack.org/#/c/594547/10/keystone/api/credentials.py | 22:48 |
| lbragstad | notice the other half of the policy check strings | 22:49 |
| lbragstad | we do "user_id:%(target.credential.user_id)s" to make sure the credential can be self-serviceable by its owner | 22:50 |
| adriant | I'd probably turn those off with: "role:admin and system_scope:all" and no 'OR' option | 22:51 |
| adriant | which should work... i think | 22:51 |
| lbragstad | yeah - that would mean you'd need to be a system admin to do anything with that | 22:51 |
| adriant | and Adjutant acts as one with it's user, so that's ok | 22:52 |
| adriant | although I know I'll need to change that a bit in Adjutant itself | 22:52 |
| adriant | because is still assuming project scope and "admin" | 22:52 |
| adriant | I like the changes. Will mean by default 'owner' can see their own creds, and if not system scoped the API is explicitly written to return only your user creds | 22:55 |
| adriant | not that I have any use for it right now, but we're not doing anything with https://github.com/openstack/keystone/blob/master/keystone/credential/backends/sql.py#L29 ? | 22:56 |
| *** hoonetorg has joined #openstack-keystone | 22:58 | |
| *** mvkr has joined #openstack-keystone | 23:10 | |
| *** dklyle has quit IRC | 23:29 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!