| cardoe | I've added a couple of items in the open section of the agenda | 16:02 |
|---|---|---|
| gouthamr | o/ cardoe; i can promote them to the main agenda.. we only have standing items as of now | 16:33 |
| gouthamr | are you okay with that? | 16:34 |
| cardoe | Yep. | 16:51 |
| cardoe | It's more free form and nothing really written down which is why I threw them there | 16:51 |
| cardoe | I can post to the ML first. | 16:51 |
| gouthamr | edited the agenda to move them to the main section, on the RBAC question, it certainly could be resolved over the ML, or pinging gmaan | 16:59 |
| gmaan | or RBAC meeting is schedule for next Monday, feel free to add there https://etherpad.opendev.org/p/rbac-goal-tracking#L98 | 17:01 |
| gmaan | ++ on ML | 17:01 |
| cardoe | oh well I'll ask gmaan then | 17:02 |
| cardoe | I guess I'll do it here... | 17:15 |
| cardoe | gmaan: reading through the RBAC bits I've come across a couple of things that just don't match with my operator hat on. | 17:15 |
| cardoe | 1. I see we tried to get rid of the system scope but then it's written up as a persona in a number of places. I don't know what the intent here us? Like I'll use neutron as an example... Granting me admin on one project grants me the ability to manipulate system wide resources. Looking at the RBAC goals... phase 1 was to get rid of system scope though. | 17:17 |
| cardoe | To use non-OpenStack terms... it seems system scope is good for non-namespaced objects. Where a namespace is a project in OpenStack terms. | 17:21 |
| cardoe | 2. We've got manager as a role but a lot of things say its just for keystone and manipulating projects. But then other places refer to it more broad. Shall we have a goal to update the definition of it to be more broad? | 17:23 |
| cardoe | 3. We've got 'auditor' referred here https://docs.openstack.org/keystone/latest/admin/service-api-protection.html shall we aim to add that role in the hierarchy so it can be used? | 17:23 |
| gmaan | cardoe: 1. for system scope, yes we the tried the system scope in all services but | 17:29 |
| gmaan | a. it did not work as integrated use case for example it broke heat, nfv use cases, | 17:29 |
| gmaan | b. operator did not understand it and did not like it. That was the key feedback from operators in forum and PTG session. | 17:29 |
| gmaan | we wrote the reason of dropping it https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#direction-change | 17:29 |
| gmaan | I know the admin being global admin a existing problem but that is what most of the operators were ok with. I do not deny to solve this issue but we do not have any perfect solution for this | 17:30 |
| cardoe | So its just awkward from the client side due to the two different tokens involved. | 17:30 |
| cardoe | I guess then we'll slash that from my agenda items. | 17:31 |
| cardoe | I'll go down this road a little bit solo then. | 17:32 |
| gmaan | we talked about global admin issue many times and being back and forth on solutions | 17:33 |
| gmaan | 2. manager role: it might be a doc but but manager role is someone between admin and project member. ity is applicable for all the services depends on their use case. for example, nova added project manager access to do live migration of user VMs belong to same project. means admin can delegate that task to project manager | 17:33 |
| gmaan | cardoe: can you please point me to the doc and I can correct it if needed or explain it more | 17:34 |
| gmaan | 3. auditor: you mean global auditor not project specific reader right? | 17:34 |
| cardoe | It could be system scoped or it could be project scoped | 17:35 |
| cardoe | The keystone docs about roles seem to imply manager is really keystone only. | 17:36 |
| gmaan | we do have project scope reader already to they can audit the things within their project | 17:36 |
| cardoe | well reading metadata about an object vs reading the whole object. | 17:37 |
| cardoe | barbican for example has this concept | 17:37 |
| cardoe | but yes auditor would likely be system scoped. | 17:37 |
| gmaan | but global reader is not there yet. it was brought up as need in vancouver summit i think 3-4 years back by john. I agreed with the idea but we just did not progress on that due to bandwidth | 17:37 |
| gmaan | I remember i added action item for John to propose the spec in keystone but it did not happen | 17:38 |
| cardoe | alright. | 17:39 |
| gmaan | but yes, it anyone would like to implement it, this is good use case | 17:39 |
| cardoe | Well I'm happy to join in on any sessions you've got in the future. | 17:39 |
| gmaan | I might not have bandwidth to do that by myself but happy to review | 17:39 |
| gmaan | ++ thanks | 17:39 |
| gmaan | and for system scope, I am able to find this etherpad where we got set back on that https://etherpad.opendev.org/p/rbac-operator-feedback | 17:40 |
| gmaan | as you know ironic implemented it and some operator were happy about it so it was kept in ironic and then in keystone for ironic use case | 17:40 |
| gmaan | * ironic operatror | 17:40 |
| gmaan | I can write about the global reader on ML and ask for any volunteer. bcz i feel like this is a good or common use case which can help many operators | 17:42 |
| gouthamr | gmaan: curious who john was in this case? garbutt? | 17:43 |
| gmaan | yes, i did not find him in IRC but John garbutt | 17:43 |
| gouthamr | ack ty | 17:44 |
| JayF | johnthetubaguy; he's not online often upstream these days | 17:52 |
| JayF | If someone needs to get in touch I can certainly find an up to date email for him | 17:52 |
| sean-k-mooney | the global auttor persona i.e. a cross project reader | 17:59 |
| sean-k-mooney | is not gernealy supproteded in most projects | 17:59 |
| sean-k-mooney | *services | 18:00 |
| JayF | https://docs.openstack.org/ironic/2026.1//admin/secure-rbac.html#system-scoped fwiw Ironic implements system reader | 18:00 |
| sean-k-mooney | nova requires admin for any cross project request for example | 18:00 |
| sean-k-mooney | systme reader shoudl only be able to read system scoped resocues | 18:00 |
| sean-k-mooney | not project scoped resourcs | 18:00 |
| sean-k-mooney | and many project dont have system scoped api. although ironic does | 18:01 |
| JayF | Ironic's a weird case here where all nodes are kinda system and can also kinda be owned by >1 project | 18:01 |
| JayF | (node.owner / node.lessee can be set to different values) | 18:01 |
| JayF | so I think our stuff is just a little weirdly shaped compared to the rest | 18:01 |
| sean-k-mooney | perhasp but its a person athat could be supproted with a new role in the future | 18:02 |
| gmaan | sent on ML https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/ZEKOWEMLY6F2RFFXVD37QRQPMB35H5PR/ | 18:02 |
| gmaan | cardoe: ^^ | 18:02 |
| sean-k-mooney | there is just no way to express "cross project reader" uniformly under the SRBAC goal today | 18:02 |
| sean-k-mooney | we could have an "audit" rule which was a readonly admin | 18:03 |
| gmaan | JayF: nothing needed on johnthetubaguy contacting. I just reminded myself that he was one who brought up the global reader need so reference it here | 18:03 |
| sean-k-mooney | it woudl just need work to enable in each of the projects | 18:03 |
| gmaan | yeah | 18:04 |
| JayF | I can probably speak to that use case too, I suspect he was representing GR's use case (among others). | 18:04 |
| JayF | and global auditor / system auditor is a good way to describe the persona | 18:04 |
| gmaan | ++ | 18:05 |
| gmaan | its not a big work other than keystone spec and doc. and then projects can start adopting it which also should not be big work. its just we need someone to start it | 18:05 |
| sean-k-mooney | JayF: i understand the usecase but we dont have a good machanic to descibe read only cross proejct access to project scoped resouce in the 5 roles we have today | 18:05 |
| sean-k-mooney | admin,manager,member,reader and service | 18:06 |
| sean-k-mooney | we coudl add a 6th role for this to that set | 18:06 |
| gmaan | 'global_reader' is the one name i thought of when it came up first | 18:06 |
| sean-k-mooney | ya that works too | 18:06 |
| gmaan | so that it will be explicit about what it means | 18:07 |
| sean-k-mooney | sure the role could be named that way rather then the usecase | 18:07 |
| sean-k-mooney | i.e. audit | 18:07 |
| sean-k-mooney | i think we all agree on the gap | 18:07 |
| sean-k-mooney | and hte actual name is less imporant | 18:07 |
| gmaan | gouthamr: FYI about email, in case you get chance to advertise it in wider way (I think this release openinfra live is done but maybe for the next one if no volunteer ) https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/ZEKOWEMLY6F2RFFXVD37QRQPMB35H5PR/ | 18:08 |
| gmaan | yeah, name things does not matter but yes its a clear need and came up many times | 18:09 |
| gouthamr | ack gmaan, makes sense | 18:10 |
| sean-k-mooney | for now you have to basiclly jsut use admin for this usecase | 18:10 |
| sean-k-mooney | not ideal | 18:10 |
| sean-k-mooney | but that the only thing that works for all services | 18:11 |
| gouthamr | similar pain as "service", a bit more dire.. | 18:12 |
| gouthamr | you don't want to give "admin" to things that should read, it'd be disasterous if something non-deterministic were to malfunction | 18:13 |
| gouthamr | like this unfortunate thing: https://x.com/lifeof_jer/status/2048103471019434248 | 18:13 |
| sean-k-mooney | well servie is also a restict but distinct form or what used to be in admin | 18:13 |
| sean-k-mooney | i.e. we created serivce so that w had a role for thigns that should only ever be called by anohter openstack service | 18:14 |
| sean-k-mooney | so that admin could not do that any more and soe we could restict what serivces could call right | 18:14 |
| gouthamr | ack, admin is the superuser, service is a subset blessed and expected by us maintainers - but our implementation has been slow | 18:15 |
| cardoe | sorry I had to wander off for a bit. | 18:16 |
| cardoe | sean-k-mooney: so an example in neutron of a system resource would be the network segment range list. | 18:17 |
| cardoe | It's pools for available VLANs. It can be configured via the ML2 config or via the API. | 18:18 |
| sean-k-mooney | cardoe: that is one way to model it | 18:19 |
| sean-k-mooney | but if you did that you could not return them in respocne to a project scoped admin token | 18:19 |
| cardoe | I'm just saying that's how it works. All projects pull from the same pool. Unless there's a private project pool. | 18:19 |
| sean-k-mooney | and operators told use we cant break glbal admin | 18:19 |
| sean-k-mooney | so using scope for this was basiclly not an option | 18:20 |
| cardoe | sean-k-mooney: I'm telling you how neutron works today. I'm not advocating for any change. | 18:20 |
| sean-k-mooney | ok so they either supprot both personas or they broke the global admin part of that goal | 18:20 |
| sean-k-mooney | it is posisbel to advertise a resouce in multiple scopes | 18:20 |
| sean-k-mooney | so them may be doing that | 18:21 |
| cardoe | It's also kinda like things that are marked "public=True" cause they're visible in all projects. | 18:21 |
| sean-k-mooney | we had made flavors and hostaggraes system scoped in nova but all that got ripped out in yoga when the change in direction was agreed | 18:21 |
| cardoe | So in this case someone with project scoped role:admin needs to see the items available to that project. | 18:22 |
| cardoe | BUT someone with admin on ANY project is allowed to manipulate what ANY project is able to see. | 18:22 |
| sean-k-mooney | project scoped does not meean limited to a project. | 18:22 |
| sean-k-mooney | the nameing is bad | 18:22 |
| sean-k-mooney | project scoepd orgnlly ment the resouce could be owned/consumed by a porject | 18:22 |
| cardoe | Well neutron also has the model of sharing a resource to another project. | 18:23 |
| sean-k-mooney | ther native rbac api | 18:23 |
| sean-k-mooney | yes nova can also have priviate flavors that are aviabel to only specfic projects | 18:23 |
| sean-k-mooney | and glance has visiablity which is not quite the same | 18:23 |
| sean-k-mooney | but simialr | 18:24 |
| sean-k-mooney | the visablity/shareablity of resocues in many cases predates the SRBAC goal and is indepentent of it | 18:24 |
| cardoe | That's fine. This one might just be better to tackle downstream. | 18:26 |
| sean-k-mooney | doign it in a portabl way will need servifce work unfortuently | 18:26 |
| sean-k-mooney | many service have a db level check that repvents cross project access without the admin role | 18:27 |
| cardoe | Yeah not the resources I'm talking about. | 18:32 |
| sean-k-mooney | do you have a list in etherpad out of interst | 18:32 |
| sean-k-mooney | the other problem with scopes is anyoen with reader can create a system scoped reader token (as far as i am aware) | 18:33 |
| sean-k-mooney | i.e. there is no way in keystone to say what scoep a user can request | 18:34 |
| cardoe | of resources? No. I'm writing a personas doc of operations. | 18:34 |
| sean-k-mooney | in keystoen you just do role assignemnt to users in a given proejct | 18:34 |
| cardoe | No. You have to have system scope in keystone | 18:34 |
| sean-k-mooney | but the entiry os scope enformce i doen out of band | 18:34 |
| sean-k-mooney | are you sure about that because i dont think that is ture | 18:35 |
| sean-k-mooney | hum maybe you are right https://docs.openstack.org/api-ref/identity/v3/index.html#system-role-assignments | 18:36 |
| sean-k-mooney | my view may be coloured by devstack | 18:38 |
| sean-k-mooney | the keyson docs are still vastly out of date so i dont know how trustworhter they are in genral | 18:40 |
| sean-k-mooney | i.e. they still use compute hypervisors | 18:40 |
| sean-k-mooney | as an exmapel fo a systme scoped api | 18:40 |
| cardoe | So just to confirm I attempted this and bypassed the service catalog and I didn't have permissions | 18:41 |
| cardoe | I am able to auth but I have no idea what I'm getting. The docs are a bit light here. | 18:42 |
| sean-k-mooney | ack so you set system_scope: all | 18:42 |
| sean-k-mooney | in your clouds.yaml | 18:42 |
| cardoe | Yep. | 18:42 |
| sean-k-mooney | looking at devstack-system-reader: | 18:43 |
| sean-k-mooney | it is actuly useing a diffent username then i tought | 18:43 |
| sean-k-mooney | i tought it sill used demo or alt-demo | 18:43 |
| sean-k-mooney | but is actully system_reader | 18:43 |
| gmaan | yeah, for system role assignment, it make sense to ask for system permission instead of allowing project admin to do | 18:44 |
| sean-k-mooney | so i guess system_reader could be used as the global_reader if that was agreed by all proejct but i dont know fi that is safe to do now | 18:44 |
| cardoe | I'm looking at this how k8s does RBAC | 18:45 |
| gmaan | but for all other operations, they will work for project scope token also along with system token. mainly keep the keystone behavior unchanged which was before system scope. that is what we fixed. if still some permission issue then its a keystone bug | 18:45 |
| sean-k-mooney | cardoe: one complication at least for nova is we also filtere the fields in the respocen based on yoru role | 18:45 |
| cardoe | Which is good. So does Ironic. | 18:45 |
| gmaan | yes, system reader is the global reader but we do not have that in any servicecs than ironic and keystone | 18:45 |
| sean-k-mooney | i.e. we dont show some fields to non admins which si part fo the issues with using reader | 18:45 |
| sean-k-mooney | well its reader access to system scoped apis | 18:46 |
| sean-k-mooney | the question is are system scoped apis prviledged or not | 18:47 |
| gmaan | sean-k-mooney: good point on hard coded admin in DB for cross project things, that is something we should get rid of irrespective of global reader use case | 18:47 |
| sean-k-mooney | gmaan: eventully but there were concersn about secuirty of remiving that final check | 18:47 |
| gmaan | it can be driven from API and based on the configured RBAC | 18:48 |
| sean-k-mooney | with some code change yes | 18:48 |
| sean-k-mooney | we cna have a cross_tenatn_allowed flag base don new or existing policy rules | 18:49 |
| sean-k-mooney | i dont know if we have all teh rules we would requried for that today but it could be done eventually | 18:50 |
| gmaan | yes, code change, idea was API to call get|do_<things>_projectA or get|do_<things>_all_projects which are control via the policy rules | 18:50 |
| gmaan | anyways not discussing that here but yes that is one of the things to fix | 18:50 |
| cardoe | sean-k-mooney: So an example I'd use for nova would be 'openstack compute agent list'. Are those project scoped at all? | 18:53 |
| sean-k-mooney | cardoe: its project scopped not system socped | 18:55 |
| sean-k-mooney | cardoe: nova had system_scoped apis and they were all removed | 18:55 |
| sean-k-mooney | so everythign in nova is project scoped now | 18:55 |
| sean-k-mooney | cardoe: one of the limiation today in oslo.policy is while its posible for a rule to have more then one scope or role i dont think its possible to say "(system_scoped:all and role:reader) or (project_admin)" | 18:59 |
| sean-k-mooney | i might be wrong about that | 18:59 |
| sean-k-mooney | but nova does nto do that even if it si posisble to express | 18:59 |
| cardoe | You are wrong | 18:59 |
| cardoe | Ironic uses that all over | 19:00 |
| sean-k-mooney | ok well nova does not | 19:00 |
| sean-k-mooney | https://github.com/openstack/nova/commit/066e1e69d1394839a9f0bde4ca8c3a0db2d52396 | 19:00 |
| cardoe | I’ll hack on this locally myself. | 19:01 |
| sean-k-mooney | looking at https://github.com/openstack/ironic/blob/master/ironic/common/policy.py | 19:03 |
| sean-k-mooney | ironic does not use scope_types | 19:03 |
| sean-k-mooney | oh yo do later | 19:03 |
| sean-k-mooney | just not on the defautl rules you use them on the per endpoitn ones | 19:03 |
| sean-k-mooney | ah and you are encodeign the check in teh check string https://github.com/openstack/ironic/blob/master/ironic/common/policy.py#L77-L103 | 19:05 |
| sean-k-mooney | so you are just using scope_types=['system', 'project'], so list the possisbel scope types you can rescie and the n doin gthe actul enfocmene in the check_str | 19:06 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!