| *** benj_8 is now known as benj_ | 06:15 | |
| opendevreview | Merged openstack/keystone stable/2025.2: Add tests for restricted app cred guard https://review.opendev.org/c/openstack/keystone/+/985887 | 09:39 |
|---|---|---|
| opendevreview | Merged openstack/keystone stable/2025.2: Block restricted app creds from creating EC2 credentials via /credentials https://review.opendev.org/c/openstack/keystone/+/985921 | 10:50 |
| opendevreview | Merged openstack/keystone stable/2025.2: Block app cred tokens from authorizing OAuth1 requests https://review.opendev.org/c/openstack/keystone/+/985924 | 10:50 |
| opendevreview | Ivan Anfimov proposed openstack/keystone stable/2025.2: Enforce app cred project boundary on EC2 credential paths https://review.opendev.org/c/openstack/keystone/+/987476 | 10:53 |
| opendevreview | Ivan Anfimov proposed openstack/keystone stable/2025.2: Block app credential token rescoping https://review.opendev.org/c/openstack/keystone/+/987477 | 10:54 |
| opendevreview | Ivan Anfimov proposed openstack/keystone stable/2025.2: Include system scope in rescope guard https://review.opendev.org/c/openstack/keystone/+/987478 | 10:54 |
| opendevreview | Ivan Anfimov proposed openstack/keystone stable/2025.2: Include system scope in rescope guard https://review.opendev.org/c/openstack/keystone/+/987478 | 10:54 |
| moutazchaara[m] | moutazchaara[m]: Good afternoon, here i have this interesting patch for you :). - Still the old one-. | 11:43 |
| moutazchaara[m] | looking forward for review/approval :) | 11:43 |
| moutazchaara[m] | moutazchaara[m]: gtema: | 11:43 |
| *** mhen_ is now known as mhen | 12:05 | |
| opendevreview | Merged openstack/keystone stable/2026.1: Block app credential token rescoping https://review.opendev.org/c/openstack/keystone/+/986498 | 12:38 |
| opendevreview | Merged openstack/keystone stable/2026.1: Include system scope in rescope guard https://review.opendev.org/c/openstack/keystone/+/986499 | 12:38 |
| opendevreview | Merged openstack/keystone stable/2026.1: Enforce app cred project boundary on EC2 credential paths https://review.opendev.org/c/openstack/keystone/+/986389 | 12:38 |
| opendevreview | Ivan Anfimov proposed openstack/keystone stable/2026.1: Block app cred tokens from authorizing OAuth1 requests https://review.opendev.org/c/openstack/keystone/+/985923 | 14:45 |
| d34dh0r53 | #startmeeting keystone | 15:05 |
| opendevmeet | Meeting started Wed May 6 15:05:25 2026 UTC and is due to finish in 60 minutes. The chair is d34dh0r53. Information about MeetBot at http://wiki.debian.org/MeetBot. | 15:05 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:05 |
| opendevmeet | The meeting name has been set to 'keystone' | 15:05 |
| d34dh0r53 | Reminder: This meeting takes place under the OpenInfra Foundation Code of Conduct | 15:05 |
| d34dh0r53 | #link https://openinfra.dev/legal/code-of-conduct | 15:05 |
| d34dh0r53 | #topic roll call | 15:05 |
| d34dh0r53 | admiyo, bbobrov, crisloma, d34dh0r53, dpar, dstanek, hrybacki, lbragstad, lwanderley, kmalloc, rodrigods, samueldmq, ruan_he, wxy, sonuk, vishakha, Ajay, rafaelwe, xek, gmann, zaitcev, reqa, dmendiza[m], dmendiza, mharley, jph, gtema, cardoe, deydra | 15:06 |
| gtema | o/ | 15:06 |
| d34dh0r53 | dmendiza: not sure if you're around, but here's your ping | 15:06 |
| gtema | :) | 15:06 |
| d34dh0r53 | :) | 15:06 |
| moutazchaara[m] | /o | 15:06 |
| dmendiza[m] | 🙋♂️ | 15:06 |
| d34dh0r53 | hi moutaz.chaara 👋 | 15:07 |
| d34dh0r53 | ohai dmendiza | 15:07 |
| d34dh0r53 | #topic review past meeting work items | 15:07 |
| d34dh0r53 | #link https://meetings.opendev.org/meetings/keystone/2026/keystone.2026-04-29-15.07.html | 15:07 |
| d34dh0r53 | no action items from last week | 15:08 |
| d34dh0r53 | #topic liaison updates | 15:08 |
| d34dh0r53 | nothing from me | 15:08 |
| gtema | nothing on my side either | 15:08 |
| d34dh0r53 | cool, moving on | 15:08 |
| d34dh0r53 | #topic specification Secure RBAC (dmendiza) | 15:08 |
| d34dh0r53 | #link https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#z-release-timeline_ | 15:08 |
| d34dh0r53 | 2026.1 Release Timeline | 15:08 |
| d34dh0r53 | Update oslo.policy in keystone to enforce_new_defaults=True | 15:08 |
| d34dh0r53 | Update oslo.policy in keystone to enforce_scope=True | 15:08 |
| dmendiza[m] | Alright, yeah, actual updates this week! | 15:09 |
| dmendiza[m] | So, there was a patch to re-enable the tox SRBAC job, which I -2'd | 15:09 |
| dmendiza[m] | because the tempest tests supersed the tox tests and we don't want to be in the business of maintaining two sets of tests for the same functionality in two different repos | 15:10 |
| dmendiza[m] | I also went ahead and fixed the tempest SRBAC tests and made the job voting: | 15:10 |
| dmendiza[m] | #link https://review.opendev.org/c/openstack/keystone-tempest-plugin/+/986031 | 15:10 |
| dmendiza[m] | Once that patch merges both keystone and keystone-tempest-plugin will switch from non-voting to voting. | 15:11 |
| gmaan | one thing on SRBAC. you might have seen the email about removal of enforce_scope | 15:11 |
| gmaan | #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/M72AY5ABQFXQ7XHLVEGHLBBK4XFQGVFK/ | 15:11 |
| gmaan | please test and let me know if all good on removal of this flag from keystone perspective | 15:12 |
| gmaan | i am sure it might need test update like i did for nova | 15:12 |
| gmaan | nova example | 15:12 |
| gmaan | #link https://review.opendev.org/c/openstack/nova/+/986946/1 | 15:12 |
| dmendiza[m] | gmaan: so it'll be enforcing scope by default after that? 🤔 | 15:12 |
| gmaan | yes | 15:13 |
| dmendiza[m] | or I guess, always enforcing scope? | 15:13 |
| gmaan | always enforcing scope | 15:13 |
| dmendiza[m] | Yeah, there were some old patches I had to fix a couple of places where we were still not using the new policies. I'll have to go back and update those to make sure we're ready for that change. | 15:13 |
| gmaan | thanks ++ | 15:13 |
| gmaan | milestone-2 (july 3rd )is deadline, please check | 15:14 |
| dmendiza[m] | once that change gets released we should be good to remove the old policies | 15:14 |
| dmendiza[m] | or maybe not? 🤔 | 15:14 |
| dmendiza[m] | I guess that depends on enforce_new_defaults not enforce_scope | 15:14 |
| gmaan | we have patches up for testing it | 15:15 |
| dmendiza[m] | gmaan: any plans to change `enforce_new_defaults`? Or change it from `false` to `true`? 🤔 | 15:15 |
| gmaan | no, it is True by default and will stay same | 15:16 |
| dmendiza[m] | Ack, I'll have to double check that we're not overriding that to false | 15:16 |
| dmendiza[m] | Dave Wilde (d34dh0r53): add an AI for me to check on those | 15:17 |
| gmaan | k | 15:17 |
| d34dh0r53 | #action dmendiza check `enforce_new_defaults` to ensure we're not overriding them to `false` | 15:18 |
| gmaan | main work if to make test work with removal of enforce_scope | 15:18 |
| dmendiza[m] | Yeah, If we're overriding one we're probably overriding both ... which we were last time I checked, but that was a while ago. | 15:19 |
| gmaan | can we please add action item for that | 15:19 |
| d34dh0r53 | #action dmendiza ensure tests are working after removal of `enforce_scope` | 15:19 |
| gmaan | thanks | 15:19 |
| d34dh0r53 | I feel like an AI bot | 15:20 |
| gmaan | dmendiza[m]: please let me know if any question on that | 15:20 |
| gmaan | dmendiza[m]: :) | 15:20 |
| dmendiza[m] | gmaan: will do, thanks | 15:20 |
| d34dh0r53 | thanks gmaan and dmendiza ++ | 15:20 |
| d34dh0r53 | next up | 15:20 |
| d34dh0r53 | #topic specification Secuirty Compliance Testing (dmendiza) | 15:20 |
| d34dh0r53 | #link https://review.opendev.org/c/openstack/devstack/+/957969 | 15:20 |
| dmendiza[m] | No progress on that one ... | 15:21 |
| dmendiza[m] | Would be cool if we can get that default change merged this cycle though | 15:21 |
| gtema | dmendiza - a reminder the real open issue is https://review.opendev.org/c/openstack/tempest/+/954029 | 15:22 |
| dmendiza[m] | Yeah, there's like 3 or 4 patches that need to land ... and changing the default value of enforcing security compliance is kind-of a prerequisite for them. | 15:23 |
| dmendiza[m] | Probably won't get to that for another week or two ... taking PTO the rest of the week after this meeting. | 15:24 |
| d34dh0r53 | ack | 15:24 |
| d34dh0r53 | thanks dmendiza | 15:24 |
| d34dh0r53 | #topic keystone-rs | 15:24 |
| d34dh0r53 | #link https://github.com/openstack-experimental/keystone | 15:24 |
| gtema | quite a progress here | 15:24 |
| gtema | so I was working on adding mTLS to keystone-rs and found a new meaning for the internal interface and system scope | 15:24 |
| gtema | so when nova/neutron/etc go to keystone with their SPIFFE managed cert they do not authenticate explicitly - they present their cert to keystone | 15:25 |
| gtema | on the keystone side it means there is a connection listening on the "internal" interface (service-to-service communication) | 15:25 |
| gtema | and the request from i.e. nova is not containing any scope info - so it is a sort of system scope | 15:26 |
| gtema | that means on internal interface by default all connections are automatically system scoped | 15:26 |
| gtema | and since I do have multiple listeners I can inject the information about the interface the request came in into the policy evaluation | 15:27 |
| gtema | that makes it possible to actually restrict certain operations also based on the interface | 15:27 |
| gtema | anyway - the mTLS implementation is in progress. While the basic listening and verifying of certs is now there I still need to manage "mappings" of the SVID (SPIFFE ID) down to the fixed scopes (actor/target/roles) | 15:28 |
| gtema | and now we have automatic config watching and reload | 15:29 |
| gtema | that's it from me for now | 15:29 |
| d34dh0r53 | wow, that's a lot of work! thanks! | 15:30 |
| d34dh0r53 | #topic open discussion | 15:30 |
| dmendiza[m] | yeah | 15:32 |
| dmendiza[m] | I did want to talk about that subtle API change that broke the SRBAC tests | 15:32 |
| dmendiza[m] | I'm not sure when it happened, but the JSON validation moved up the priority queue for processing a request | 15:33 |
| dmendiza[m] | which changed the response code in some situations | 15:33 |
| dmendiza[m] | In our tests, whenever we try to do something with a non-existent entity we expect a 404 - Not Found | 15:34 |
| dmendiza[m] | But in the PATCH API for domains (and maybe other APIs, I did not check) the JSON validation happens before the DB query | 15:35 |
| dmendiza[m] | For these specific tests, we were expecting and getting 404s | 15:36 |
| dmendiza[m] | and when the JSON validation started happening we started getting 400 - Bad Request | 15:36 |
| dmendiza[m] | because the PATCH body was invalid | 15:36 |
| gtema | we knew that and discussed in particular before starting adding validators | 15:37 |
| gtema | there is no way to deal with this | 15:37 |
| gtema | and it is really arguable that this is a correct behavior | 15:37 |
| dmendiza[m] | Yeah, arguably we should 404 before processing a request | 15:38 |
| dmendiza[m] | so we could argue it either way | 15:38 |
| dmendiza[m] | e.g. why would I validate a request since I'm not going to do anything with it anyway | 15:39 |
| dmendiza[m] | or maybe an argument of order of validation | 15:39 |
| dmendiza[m] | we should validate that the UUID exists befor validating that we want to modify the entity associated with it | 15:39 |
| gtema | it's actually a default behavior of majority of the frameworks to deserialize the request before passing it into the handler. And only inside the handler you can verify whether the target actually exist | 15:39 |
| dmendiza[m] | I wonder if that is a limitation of Flask? | 15:40 |
| dmendiza[m] | because we deal with this no problem with Barbican, but we use Pecan there. | 15:40 |
| gtema | not only flask - as said majority of frameworks | 15:40 |
| gtema | it's a question of where you define the corresponding schema - on the handler level or inside your logic | 15:41 |
| cardoe | So potentially one part of what you're having an issue with is that we mentally treat 400 Bad Request different than it's suppose to be treated. | 15:41 |
| cardoe | 400 Bad Request just means what you sent is trash | 15:41 |
| gtema | when inside your logic neither the framework nor codegenerator nor anything else can do anything useful with it (e.g., generate openapi spec for such handler) | 15:41 |
| cardoe | 429 means you didn't send a field or something didn't pass validation | 15:42 |
| gtema | typically you say that the handler expects a certain body schema | 15:44 |
| dmendiza[m] | 429 - Too Many Requests 🤔 https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/429 | 15:44 |
| gtema | and return a certain response schema | 15:44 |
| gtema | that means the framework need to deserialize the request even before it hits the handler | 15:44 |
| dmendiza[m] | we could also argue that, given that the uuid is part of the path, that sending a request to a path that does not exist should always 404 🤔 | 15:45 |
| gtema | dmendiza - another aspect is that you should return 403\401 instead of 404 not to even expose the fact of existence/non-existence of the resource. So 400 is behaving similarly | 15:46 |
| gtema | designate give you 400 even for GET request when the uuid is not matching the uuid form | 15:46 |
| dmendiza[m] | gtema: I think you have that backwards ... 404 instead of 401 so that you don't divulge that something does exist | 15:47 |
| gtema | that is really creapy | 15:47 |
| gtema | dmendiza - actually not. If you return 404 before the 401 you signal the resource does not exist and when you find the existing resource you will get 401/403 instead. So this way you can "scan" | 15:48 |
| dmendiza[m] | Yeah, that's what I'm saying ... when you don't have the right permission you should get a 404 so that you never know if somethign exists or not | 15:49 |
| dmendiza[m] | I guess you could argue that 401 always could do the same. 🤷 | 15:49 |
| gtema | but that is technically the same - you do some validation before you actually look for the resource | 15:49 |
| gtema | I mean same to the request validation before checking for resource existence | 15:50 |
| dmendiza[m] | It's confusing either way ... for a valid user getting a 401 would make them think they have to update their credentials instead of letting them know that the resource they want does not exist. | 15:50 |
| d34dh0r53 | I think 404 is correct, "The 404 (Not Found) status code indicates that the origin server did | 15:50 |
| d34dh0r53 | not find a current representation for the target resource or is not | 15:50 |
| d34dh0r53 | willing to disclose that one exists." from the RFC | 15:50 |
| gtema | but 400 is also correct - "a client-side error indicating that the server cannot process the request due to malformed syntax, invalid request message framing, or deceptive routing" | 15:51 |
| d34dh0r53 | yeah, I see your point, whatever it is it needs to be consistent to prevent scanning | 15:52 |
| dmendiza[m] | Yeah, in any case, I'm not really aruging for any particular outcome here. I just wanted to make y'all aware that Keystone API behavior changed since the last time that the SRBAC test suite was passing/voting | 15:53 |
| d34dh0r53 | yeah, and that's likely undocumented | 15:53 |
| dmendiza[m] | which it sounds like we already discussed in the past and I missed it/forgot it | 15:53 |
| gtema | yes, this is not SRBAC related but openapi decorators related and was mentioned | 15:54 |
| d34dh0r53 | do we need an action item for this one? | 15:54 |
| dmendiza[m] | Nope ... sounds like we would need to figure out how to get Flask to query the entity before processing the handler, and I'm not sure I have time to do that currently. Maybe an AI to document that 400 takes precedence over 404s in the API? | 15:55 |
| dmendiza[m] | Action Item, not AI AI :-P | 15:55 |
| gtema | we can't and should not change the behavior, so we should rather update docs | 15:56 |
| gtema | I even remember I was documenting it somewhere, maybe release notes of some of the first changes | 15:57 |
| d34dh0r53 | #action ??? document that 400 takes precedence over 404s in the API | 15:57 |
| d34dh0r53 | moving on for time | 15:57 |
| d34dh0r53 | #topic bug review | 15:57 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystone/?orderby=-id&start=0 | 15:57 |
| d34dh0r53 | wow, no new bugs in keystone | 15:58 |
| d34dh0r53 | #link https://bugs.launchpad.net/python-keystoneclient/?orderby=-id&start=0 | 15:58 |
| d34dh0r53 | python-keystoneclient is good | 15:58 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystoneauth/+bugs?orderby=-id&start=0 | 15:58 |
| d34dh0r53 | keystoneauth is good as well | 15:58 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystonemiddleware/+bugs?orderby=-id&start=0 | 15:58 |
| d34dh0r53 | nothing new in keystonemiddleware | 15:58 |
| d34dh0r53 | #link https://bugs.launchpad.net/pycadf/+bugs?orderby=-id&start=0 | 15:58 |
| d34dh0r53 | pycadf is fine | 15:59 |
| d34dh0r53 | #link https://bugs.launchpad.net/ldappool/+bugs?orderby=-id&start=0 | 15:59 |
| d34dh0r53 | and, no new bugs in ldappool | 15:59 |
| d34dh0r53 | #topic conclusion | 15:59 |
| moutazchaara[m] | Sorry to interrupt the current discussion, but when you have a moment:... (full message at <https://matrix.org/oftc/media/v1/media/download/AXjarbTrGxwCySY4eiJ5ko69evKToJ2pdcGbsouCuIj2cmYDApA5Do-oc2JHb3CnS5rFVPZbTS23EtNOVdVcQPdCeeRh00jQAG1hdHJpeC5vcmcvRHNLU1JhV1l3QVRnckJBV2ZTUnp0Wm1j>) | 15:59 |
| moutazchaara[m] | gtema: | 15:59 |
| gtema | it is between 100 other tabs for review unfortunately | 16:00 |
| gtema | and I even looked at it today, just didn't complete | 16:00 |
| d34dh0r53 | moutaz.chaara: I'll take a look at this as well | 16:00 |
| moutazchaara[m] | All good at least on your list ;) | 16:00 |
| moutazchaara[m] | Yeah appreciate that, i already had +2 but i discovered something and thought to improve it | 16:01 |
| d34dh0r53 | cool, thanks everyone! | 16:02 |
| gtema | thanks guys | 16:02 |
| d34dh0r53 | #endmeeting | 16:02 |
| opendevmeet | Meeting ended Wed May 6 16:02:36 2026 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:02 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/keystone/2026/keystone.2026-05-06-15.05.html | 16:02 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/keystone/2026/keystone.2026-05-06-15.05.txt | 16:02 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/keystone/2026/keystone.2026-05-06-15.05.log.html | 16:02 |
| gtema | dmendiza - do you have few minutes still? | 16:02 |
| opendevreview | Merged openstack/keystone stable/2026.1: Block app cred tokens from authorizing OAuth1 requests https://review.opendev.org/c/openstack/keystone/+/985923 | 17:00 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!