| opendevreview | Stanislav Zaprudskiy proposed openstack/keystone master: Support emitting partial hash of invalid password https://review.opendev.org/c/openstack/keystone/+/932423 | 12:56 |
|---|---|---|
| *** ykarel_ is now known as ykarel | 13:43 | |
| d34dh0r53 | #startmeeting keystone | 15:02 |
| opendevmeet | Meeting started Wed Jan 15 15:02:02 2025 UTC and is due to finish in 60 minutes. The chair is d34dh0r53. Information about MeetBot at http://wiki.debian.org/MeetBot. | 15:02 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:02 |
| opendevmeet | The meeting name has been set to 'keystone' | 15:02 |
| xek | o/ | 15:02 |
| gtema | o/ | 15:02 |
| d34dh0r53 | Reminder: This meeting takes place under the OpenInfra Foundation Code of Conduct | 15:02 |
| d34dh0r53 | #link https://openinfra.dev/legal/code-of-conduct | 15:02 |
| d34dh0r53 | #topic roll call | 15:02 |
| 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 | 15:02 |
| d34dh0r53 | and a special ding for dmendiza | 15:03 |
| d34dh0r53 | :) | 15:03 |
| dmendiza[m] | 🙋♂️ | 15:03 |
| cardoe | o/ | 15:03 |
| gtema | lol | 15:03 |
| d34dh0r53 | o/ | 15:04 |
| d34dh0r53 | #topic review past meeting work items | 15:04 |
| d34dh0r53 | #link https://meetings.opendev.org/meetings/keystone/2025/keystone.2025-01-08-15.01.html | 15:05 |
| d34dh0r53 | had to update the link | 15:05 |
| d34dh0r53 | no action items from the last meeting | 15:05 |
| d34dh0r53 | #topic liaison updates | 15:05 |
| d34dh0r53 | nothing from releases or vmt | 15:05 |
| d34dh0r53 | #topic specification OAuth 2.0 (hiromu) | 15:07 |
| d34dh0r53 | #link https://review.opendev.org/q/topic:bp%252Foauth2-client-credentials-ext | 15:08 |
| d34dh0r53 | #link https://review.opendev.org/q/topic:bp%252Fenhance-oauth2-interoperability | 15:08 |
| d34dh0r53 | External OAuth 2.0 Specification | 15:08 |
| d34dh0r53 | #link https://review.opendev.org/c/openstack/keystone-specs/+/861554 (merged) | 15:08 |
| d34dh0r53 | OAuth 2.0 Implementation | 15:08 |
| d34dh0r53 | #link https://review.opendev.org/q/topic:bp%252Fsupport-oauth2-mtls | 15:08 |
| d34dh0r53 | OAuth 2.0 Documentation | 15:08 |
| d34dh0r53 | #link https://review.opendev.org/c/openstack/keystone/+/838108 (merged) | 15:08 |
| d34dh0r53 | #link https://review.opendev.org/c/openstack/keystoneauth/+/838104 (merged) | 15:08 |
| d34dh0r53 | no updates | 15:08 |
| d34dh0r53 | #topic specification Secure RBAC (dmendiza[m]) | 15:10 |
| d34dh0r53 | #link https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#z-release-timeline_ | 15:10 |
| d34dh0r53 | 2024.1 Release Timeline | 15:10 |
| d34dh0r53 | Update oslo.policy in keystone to enforce_new_defaults=True | 15:10 |
| d34dh0r53 | Update oslo.policy in keystone to enforce_scope=True | 15:10 |
| d34dh0r53 | dmendiza: any SRBAC updates? | 15:10 |
| dmendiza[m] | Negative... | 15:11 |
| dmendiza[m] | I shoudl get back to that some time soon hopefully | 15:11 |
| d34dh0r53 | cool, thanks dmendiza | 15:11 |
| d34dh0r53 | #topic specification OpenAPI support (gtema) | 15:11 |
| d34dh0r53 | #link https://review.opendev.org/q/topic:%22openapi%22+project:openstack/keystone | 15:12 |
| gtema | thanks Dave for reviewing some changes | 15:12 |
| gtema | generally - there are things to review and land | 15:12 |
| gtema | further work is in progress | 15:12 |
| xek | I'll get to reviewing those soon | 15:12 |
| gtema | btw, I started work on building openapi for barbican, which is not trivial ;-) | 15:13 |
| d34dh0r53 | woot | 15:13 |
| dmendiza[m] | Oh, yeah, Barbican API is kinda ugly in some parts | 15:13 |
| gtema | not only that, I mean introspecting the code is not really possible without hardcoding routing table due to the extensive use of dynamic routing | 15:14 |
| gtema | because of that I can only natively find only half of the routes | 15:14 |
| gtema | I got request from somebody in the community to add this | 15:15 |
| gtema | so anyway, will look further in next days, but keystone jsonschemas are in progress but need reviews ;-) | 15:15 |
| gtema | nothing else on that | 15:15 |
| d34dh0r53 | thanks gtema | 15:16 |
| d34dh0r53 | #topic specification domain manager (mhen) | 15:16 |
| d34dh0r53 | still unmerged are: | 15:16 |
| d34dh0r53 | documentation: https://review.opendev.org/c/openstack/keystone/+/928135 | 15:16 |
| d34dh0r53 | tempest tests: https://review.opendev.org/c/openstack/keystone-tempest-plugin/+/924222 | 15:16 |
| d34dh0r53 | dmendiza: mind taking a look at those? | 15:16 |
| dmendiza[m] | Yeah... I need to get back to reviewing things 😅 | 15:17 |
| d34dh0r53 | No worries, it's been a busy few months | 15:18 |
| gtema | yeah, Christmas, New Year and such sort of things ;-) | 15:18 |
| d34dh0r53 | #topic specification Include bad password details in audit messages (stanislav-z) | 15:19 |
| d34dh0r53 | #link https://review.opendev.org/c/openstack/keystone-specs/+/915482 | 15:19 |
| d34dh0r53 | #link https://review.opendev.org/q/topic:%22pci-dss-invalid-password-reporting%22 | 15:19 |
| d34dh0r53 | 15-Jan update: there are some open conversations in the spec - would appreciate the feedback and general reviews | 15:19 |
| stanislav-z | yes, turned out I had my responses in the keystone-spec submitted weeks ago, but not published 😞. but I did it today | 15:19 |
| gtema | ok, will have a look this week (if nothing explodes) | 15:20 |
| d34dh0r53 | thanks gtema | 15:21 |
| d34dh0r53 | #topic open discussion | 15:21 |
| d34dh0r53 | nothing from me | 15:21 |
| gtema | I have few things | 15:21 |
| gtema | I mentioned last friday I joined SysEleven and there is interesting usage of OpenFGA for managing authorization externally | 15:21 |
| gtema | so I created role-assignment plugin for communicating with openfga | 15:22 |
| gtema | but noticed that if we want to delegate role assignments to the external system which itself is capable dealing with role inference and inheritance there is no way to do this in driver | 15:22 |
| gtema | basically keystone role-assignment provider is enforcing lots of things which can be done in the external system (openfga/aws cedar/opa/etc) | 15:23 |
| dmendiza[m] | O | 15:23 |
| dmendiza[m] | O | 15:23 |
| gtema | I think it would make sense to have possibility to externalize this more natively | 15:23 |
| dmendiza[m] | I've got something too | 15:23 |
| gtema | i.e. there is a call to list_role_assignments which gets bazilion of params and is being invoked few times | 15:24 |
| gtema | which this is not necessary if external system can deal with that and it doesn't differentiate between "effective" roles and direct what might be necessary | 15:25 |
| gtema | so: are you guys ok reworking role-assignment provider slightly to allow to put all logic to the external system if such system support that? | 15:25 |
| gtema | basically for now it means splitting some methods to allow more granular overloading and having possibility to disable auth caching to allow roles being read dynamically from external system | 15:26 |
| xek | I'm for it +1 | 15:27 |
| gtema | cool, thks. This is more or less for now to allow external system to make decision which roles are assigned to the user | 15:28 |
| gtema | and a second question: here they do not use domains at all and (together with keycloak and openfga) manage user/projects directly under the default domain | 15:29 |
| gtema | I am struggling at the moment to find enough arguments against that (to start using domains for better segregation). Do you know any reasons why this should be preferred in a public cloud? | 15:29 |
| gtema | statement "it is not scalable" is not sufficient, I need something with more weight | 15:30 |
| dmendiza[m] | The main use of Domains is to group Projects together. In a public cloud you could map a client's account to be their domain. That way a single account could own many projects while being insulated from other accounts. | 15:31 |
| gtema | right, but it is also possible to grant user(s) access to projects directly bypassing domains grouping | 15:32 |
| dmendiza[m] | I think the main argument for Domains would be the Domain Manager persona whereby you could have an end user manage permissions for their domain as opposed to having to call the deployer every time. | 15:32 |
| gtema | I was thinking more into the performance of certain queries, quotas/limits or similar stuff | 15:32 |
| gtema | correct, domain manager is here a perfect fit, but if permissions are managed externally (because they want to unify authz for openstack/kubernetes/ceph/etc all the other things) | 15:33 |
| gtema | then domain manager becomes somehow unnecessary (or better to say not appliable). Anyway, I definitely ack that and it is one of the arguments, but I need a bit more | 15:34 |
| dmendiza[m] | Yeah, I'm not sure about performance implications. 🤔 | 15:37 |
| gtema | when domain_id is part of the index then it is definitely faster to find entry | 15:38 |
| gtema | but whether it is "noticable" I have no clue | 15:38 |
| gtema | and since all other services do not deal with domains, but only with projects it is hard to justify | 15:39 |
| gtema | anyway, if there are no known things - thanks | 15:41 |
| gtema | will still try to convince from the "upstream and all other CSPs" do it this way | 15:41 |
| dmendiza[m] | On my end, I still need to file a LP bug for this, but we found a breaking bug in the LDAP backend | 15:42 |
| dmendiza[m] | Bugfix patch is here, but it's currently failing the gate jobs: https://review.opendev.org/c/openstack/keystone/+/939172 | 15:43 |
| d34dh0r53 | I haven't looked yet, any idea what's failing? | 15:45 |
| gtema | looks mypy is now complaining in pep8 checks | 15:45 |
| gtema | I will have a look today/tomorrow whether there is a new gate blocker due to updated additional SW | 15:46 |
| d34dh0r53 | thanks gtema | 15:46 |
| d34dh0r53 | anything else for open discussion? | 15:46 |
| gtema | not from me | 15:46 |
| d34dh0r53 | cool | 15:47 |
| d34dh0r53 | #topic bug review | 15:47 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystone/?orderby=-id&start=0 | 15:47 |
| d34dh0r53 | no new bugs in keystone | 15:47 |
| d34dh0r53 | #link https://bugs.launchpad.net/python-keystoneclient/?orderby=-id&start=0 | 15:48 |
| d34dh0r53 | python-keystoneclient has no new bugs | 15:48 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystoneauth/+bugs?orderby=-id&start=0 | 15:48 |
| d34dh0r53 | nothing in keystoneauth either | 15:48 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystonemiddleware/+bugs?orderby=-id&start=0 | 15:48 |
| d34dh0r53 | keystonemiddleware is good | 15:48 |
| d34dh0r53 | #link https://bugs.launchpad.net/pycadf/+bugs?orderby=-id&start=0 | 15:48 |
| d34dh0r53 | pycadf is also good | 15:48 |
| d34dh0r53 | #link https://bugs.launchpad.net/ldappool/+bugs?orderby=-id&start=0 | 15:48 |
| d34dh0r53 | no new bugs in ldappool | 15:48 |
| d34dh0r53 | #topic conclusion | 15:49 |
| d34dh0r53 | Thanks everyone! | 15:49 |
| gtema | thks guys | 15:49 |
| d34dh0r53 | #endmeeting | 15:49 |
| opendevmeet | Meeting ended Wed Jan 15 15:49:16 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:49 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/keystone/2025/keystone.2025-01-15-15.02.html | 15:49 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/keystone/2025/keystone.2025-01-15-15.02.txt | 15:49 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/keystone/2025/keystone.2025-01-15-15.02.log.html | 15:49 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!