| *** kevko7 is now known as kevko | 12:25 | |
| gmaan | #startmeeting policy_popup | 18:01 |
|---|---|---|
| opendevmeet | Meeting started Mon May 4 18:01:32 2026 UTC and is due to finish in 60 minutes. The chair is gmaan. Information about MeetBot at http://wiki.debian.org/MeetBot. | 18:01 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 18:01 |
| opendevmeet | The meeting name has been set to 'policy_popup' | 18:01 |
| gmaan | #link https://etherpad.opendev.org/p/rbac-goal-tracking#L100 | 18:01 |
| gmaan | today agenda | 18:01 |
| gmaan | I will cover the two things here and we can discuss if anyone joined or would like to discuss | 18:02 |
| gmaan | #topic Reviews: | 18:02 |
| gmaan | #link https://review.opendev.org/c/openstack/horizon/+/927342 | 18:03 |
| gmaan | this is still pending on me, I need to test it more before open it for review | 18:03 |
| gouthamr | o/ | 18:03 |
| gmaan | gouthamr: o/ | 18:03 |
| gmaan | #topic Open Discussion: | 18:04 |
| gmaan | Global reader: | 18:04 |
| gmaan | discussion started on ML, but i asked for volunteer and artem raised hand | 18:04 |
| gmaan | #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/ZEKOWEMLY6F2RFFXVD37QRQPMB35H5PR/ | 18:04 |
| gmaan | anything on this to discuss other than what is discussed on ML | 18:05 |
| gouthamr | it looks like we could use a spec and re-design | 18:06 |
| gmaan | yes, start will be a spec in keystone like we did for manager role | 18:07 |
| gouthamr | some of the questions on that discussion weren't as straight forward.. basically we need a "admin+readonly" role from what i recall the previous discussion | 18:07 |
| gmaan | once we have that role in keystone/bootstrap then projects can start adding it | 18:07 |
| gmaan | admin already has that capability it can read things everywhere | 18:07 |
| gmaan | here we need a reader who can read across projects | 18:08 |
| gmaan | but no write permission | 18:08 |
| gmaan | if that user need some right operation then required additional write can be assigned | 18:08 |
| gouthamr | yes, excuse my framing of this.. i mean a "system scoped reader" in today's context can be reinterpreted as a "reader" but across projects, like "admin" | 18:08 |
| gouthamr | i wonder if, we could do something in oslo-policy and keystone alone to enable this without changes to existing projects | 18:09 |
| gmaan | yeah, we will not have system scope but idea is to have a reader capability in complete system | 18:09 |
| gmaan | it need project code change as it is not just policy control because many projects has hardcoded admin check or query by project_id in DB | 18:10 |
| gmaan | I will say that is the big work here. keystone spec and bootstrap changes are small but needed for projects to start | 18:11 |
| gouthamr | ack, but, those checks today can be bypassed by "role: admin".. so, if we did allow oslo-policy to "imply" permissions for this special role, we could solve this? | 18:11 |
| gmaan | for example, nova checks the admin in DB access so we need a good amount of code change there | 18:11 |
| gmaan | did not get? imply permission of new role to admin or otherway? | 18:12 |
| gmaan | new role should just imply the reader role hierarchy, it should not imply any higher permission role | 18:13 |
| gmaan | and also, oslo.policy should not imply the role permission instead that is controlled by the keystone as authorization module | 18:14 |
| cardoe | So some of the interest would also be more permissions than reader. Hence why I said auditor. | 18:14 |
| cardoe | So nova for exa | 18:14 |
| cardoe | Example hides the hypervisor if you aren’t admin. | 18:14 |
| cardoe | But openstack-exporter for example, it would be handy to see the hypervisor. | 18:14 |
| gmaan | that is tricky and that is the reason we want to keep admin things away from auditor | 18:15 |
| gmaan | I mean that was what system reader was designed for | 18:15 |
| cardoe | That’s why I was saying it might be good to start with a description of the persona of the use case. | 18:16 |
| cardoe | System reader could hide things away. | 18:16 |
| gouthamr | interesting, if you're operating across projects, it should be as good as a (read-only) administrator? is there any benefit from paring this down further? | 18:16 |
| gouthamr | across projects/domains | 18:16 |
| cardoe | I actually started trying to define out these roles in ironic. Lemme find a link. | 18:17 |
| gmaan | global reader knowing admin level info also risk | 18:17 |
| gouthamr | ack, i'd like to see an example... i can respond to gmaan's thread with a better articulated version of my idea so you can find holes | 18:18 |
| gmaan | for example, nova does not allow non-admin user to live migrate by specifying the host but if a reader can know host info then it is risk for non-admin users to know the same and try live migration | 18:18 |
| gouthamr | oh, but that'd fail? | 18:19 |
| gmaan | I think there are two separate use case ask: global reader + global admin reader | 18:19 |
| cardoe | https://review.opendev.org/c/openstack/ironic/+/986702 | 18:19 |
| gouthamr | oh, i forgot nova lets managers to live migrate.. but, currently, not knowing the host names is the security measure against managers moving things somewhere they aren't supposed to? :D | 18:20 |
| cardoe | So in our case we've got "Cloud Admins". Which these folks are our OpenStack admins. They know OpenStack and manage it and run it. | 18:20 |
| gmaan | yeah but allowing reader to know host things is also security risk | 18:20 |
| cardoe | But we've also got "Cloud Operators" if you'll excuse the bad names. These folks aren't our OpenStack admins. But they handle the operational issues with hypervisors for example and other hardware. | 18:21 |
| gmaan | cardoe: yeah, I think the is sovled in ironic anyways with the system reader but yes system level admin thing reader is not | 18:21 |
| cardoe | Tools like openstack-exporter would be able to gather information like the hypervisor that instances are on to help us correlate and say "boxes matching pattern X" are leading to issue Y being reported. | 18:22 |
| cardoe | But it's ultimately a read-only user that would be scraping that data. | 18:22 |
| gmaan | I am not against of 'global admin reader/exporter' but we still need the 'global reader (without knowing the system info)' as first step | 18:22 |
| cardoe | gmaan: I don't disagree. | 18:23 |
| cardoe | I'm advocating for a handful of use cases here. | 18:23 |
| gmaan | ++ | 18:23 |
| cardoe | and while I'm linking an ironic doc, I'm using examples of not having ironic in play. | 18:23 |
| cardoe | I started out in ironic by writing a description of these types of users and what I'm saying is that I'm happy to write this up more generically somewhere else. | 18:24 |
| cardoe | And giving these users a fictitious name like "Ollie the Cloud Operator" and "Amy the Cloud Admin". Which is what I've seen done at many orgs for doing product feature planning / management. | 18:24 |
| gmaan | thanks, I think that is good direction. and keystone is the right place to describe it more generically | 18:24 |
| cardoe | Like "who do you expect to use this feature" | 18:25 |
| gouthamr | gmaan: i think it's easier to work on the "admin+reader" thing though.. i can take a deeper look at implications and get back | 18:25 |
| cardoe | In small scale deployments one person might have many hats. | 18:25 |
| gouthamr | easier to first work* | 18:25 |
| cardoe | At Rackspace how we've handled some of this is to have a service that reads the MySQL DB directly. | 18:26 |
| gmaan | gouthamr: sure but let's keep both idea separate and spec so that we do not hold either of it if some objection | 18:26 |
| cardoe | I believe I've seen in Vexxhost's repos that they do the same thing as Rackspace. | 18:26 |
| gouthamr | gmaan: ++ | 18:26 |
| cardoe | I know OVH has something similar as well. | 18:26 |
| gmaan | cardoe: so that is specific service not role which is used to assign to users for DB read right? | 18:27 |
| gmaan | and used for debuggin only or any other use case? | 18:28 |
| cardoe | It's a completely external service to work around the cases like you've mentioned where the project info is necessary in the nova DB access. | 18:28 |
| cardoe | So attempting to access multiple projects at once is just not feasible today via the API. | 18:28 |
| gmaan | yeah, API restrict that at least currently | 18:29 |
| cardoe | I'm just trying to step back and ask "why is it being done this way" | 18:29 |
| gmaan | I think doing those both reader role will be good and can avoid direct DB read or so | 18:29 |
| cardoe | And it's done this way because nova doesn't have that use case as something that's supported or even in their goals. | 18:29 |
| cardoe | And why not? Because there's no definition of a role that would work to secure that. | 18:30 |
| cardoe | At least that's how I'm coming to the conclusion. | 18:30 |
| gmaan | cardoe: I do not think we had any reason of 'doing this way' it is more of we are getting more ask/use case of it now and nobody is rejecting. In past also(AFAIK), nobody rejected it. Its just nobody started it. | 18:31 |
| cardoe | Yep. Not saying anybody rejected it. | 18:31 |
| gmaan | system reader was one of the idea to solve it but once we dropped system scoped role then nobody carry forward that use case and implemented alternate | 18:32 |
| cardoe | I'm just trying to not be hacky about it and do it the right way | 18:33 |
| gmaan | honestly saying in my previous org (and current org also) I volunteer for the RBAC goal and tried my best as much as I can. | 18:33 |
| gmaan | there was no direct use case of these new role in my previous organization. and we lacked other org to come forwards and improve the RBAC | 18:33 |
| gmaan | i agree, whole effort of SRBAC is to make defaults more usable the do hack. | 18:34 |
| gmaan | *then do | 18:34 |
| gouthamr | ack ty for all the pain so far, it's been a kinda sad state not to get the stated goal past the finish line too.. | 18:34 |
| gouthamr | while we can discuss these improvements in parallel, where are we stuck on the current goal? | 18:35 |
| gmaan | anyways I will wait for the specs and we can review it in detail covering the exact use cases | 18:35 |
| gmaan | gouthamr: current goal is all good. These new use case are expanding the goal. | 18:35 |
| gmaan | I do not think we need to drag the goal for every use case or every role. I will say it can move forward independent of goal also | 18:36 |
| gmaan | if we want to track it as a goal I will say we can start a new one instead of creating confusion on re-timelined the current goal | 18:36 |
| gouthamr | yes | 18:36 |
| cardoe | Yeah this can be a new one. | 18:37 |
| gmaan | and not sure if all projects need such global reader accounts | 18:37 |
| gmaan | I will say steps can be: | 18:39 |
| gmaan | 1. spec in keystone for new roles | 18:39 |
| gmaan | 2. implementation of the new role in keystone with bootstrap + imply other role if needed | 18:39 |
| gmaan | 3. documentation in keystone to define 'what are these role and who should use it'. like what cardoe trying with other personas | 18:39 |
| gmaan | 4. ask projects to adopt those | 18:39 |
| gmaan | as artem volunteer it and he is also keystone maintainer it matches with the above required steps | 18:40 |
| gmaan | of course other member can join the effort | 18:40 |
| gmaan | 4th one is project side which can be more work or less or no work at all which depends on how project implementation is | 18:40 |
| gmaan | anything else on this ? | 18:41 |
| gouthamr | ++ | 18:41 |
| gouthamr | nothing from me. will think about this some more; but want to discuss the current goal a bit more | 18:42 |
| gmaan | sure | 18:42 |
| gmaan | let's close meeting then. thanks gouthamr cardoe for joinging | 18:42 |
| gmaan | gouthamr: oh you mean to discuss today in meeting or later? | 18:43 |
| gouthamr | if phase 2 (service role) and phase 3 (project manager role) aren't done by someone, it could just mean that the OpenStack service doesn't care about this? | 18:43 |
| gouthamr | sorry, yes, was taking a minute to formulate that question | 18:43 |
| gouthamr | i'm wondering how long we'll keep this goal around | 18:43 |
| gmaan | not sure, i have been asking the same question to projects but no clear answer | 18:43 |
| gmaan | as discussed in PTG, I will contionue the removal of enforce-scope things andin next PTG we can iterate on if we close or not | 18:44 |
| gouthamr | that's great, ty for https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/M72AY5ABQFXQ7XHLVEGHLBBK4XFQGVFK/ | 18:44 |
| gmaan | removal of enforce-scope is the last things to do other than phase wise progress | 18:45 |
| gmaan | I will be sending the nova as an example to fix the testing on that | 18:45 |
| gouthamr | ack, would be helpful | 18:45 |
| gouthamr | you're targeting this to milestone-2 (July 3rd) | 18:45 |
| gmaan | yes | 18:45 |
| gouthamr | thanks, good amount of time.. unless project teams are ignoring the urgency in your email :D | 18:46 |
| gmaan | yeah, I will send more reminder in between but let's see | 18:46 |
| gouthamr | #link https://etherpad.opendev.org/p/rbac-goal-tracking#L79 | 18:46 |
| gouthamr | this is the list we know of atm | 18:46 |
| gmaan | yes | 18:46 |
| gouthamr | i'll try to reiterate this with the TC and through the weekly email | 18:47 |
| gmaan | i send the same in ML and also changes in gerrit | 18:47 |
| gmaan | ++ | 18:47 |
| gmaan | ++ | 18:47 |
| gmaan | that will be helpful | 18:47 |
| gouthamr | ack, based on the results of our testing, i was going to suggest wrapping up the goal | 18:48 |
| gouthamr | and writing up a recommendation document on "service" and "manager" personas | 18:48 |
| gmaan | yeah, once enforce_scope is removed I will try to wrap it up | 18:48 |
| gmaan | yeah | 18:48 |
| gouthamr | thanks gmaan, that's all i had :) | 18:49 |
| gmaan | k | 18:49 |
| gmaan | let's close then, thanks again for the discussion | 18:49 |
| gmaan | #endmeeting | 18:49 |
| opendevmeet | Meeting ended Mon May 4 18:49:30 2026 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 18:49 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/policy_popup/2026/policy_popup.2026-05-04-18.01.html | 18:49 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/policy_popup/2026/policy_popup.2026-05-04-18.01.txt | 18:49 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/policy_popup/2026/policy_popup.2026-05-04-18.01.log.html | 18:49 |
| cardoe | gouthamr: writing it up in keystone docs? | 20:12 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!