| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-10-05 | |||
| 17:47:10 | sean-k-mooney | ya althoght we have had a usecase propsed int he past where an operator might want to send a network-changed event to referesh the network info cache | |
| 17:47:42 | dansmith | well, we used to have a dedicated API for that, but yes, that's kinda what I mean... those sorts of things | |
| 17:47:49 | sean-k-mooney | its an interesting problem. i dont think we have any other cases where we might want to very the policy based on a sub feild of the request body | |
| 17:48:06 | sean-k-mooney | in this case the event type | |
| 17:48:11 | dansmith | well, I think we can just manually enforce that in code | |
| 17:48:44 | dansmith | I dunno, I just don't want to call this system scope only and eliminate the possibility to use it for human-triggered things in the future | |
| 17:48:51 | sean-k-mooney | i dont think oslo policy can do this today so ya we would have to do it on the nova side | |
| 17:49:28 | sean-k-mooney | well if we assume it remaind amin only the the operator could create a system scoped token ot interact with it | |
| 17:49:40 | sean-k-mooney | but its not exactly a user freindly approch | |
| 17:50:13 | dansmith | but that's not necessarily always an admin thing | |
| 17:50:49 | gmann | default value or scope cannot by handle dynamically in oslo but yes a new policy enforcement based on request field can be added in code | |
| 17:51:00 | sean-k-mooney | this is one api that is currently not usable by nova client or osc by the way | |
| 17:51:07 | dansmith | I know | |
| 17:51:27 | sean-k-mooney | the reason i bring that up is i have wondered if we should close that gap in the past | |
| 17:51:52 | sean-k-mooney | but i have never actully looked at doing that since right now we have no usage that is human trigggered | |
| 17:52:39 | lbragstad | could you rewrite the policy to be service specific? | |
| 17:52:44 | lbragstad | instead of system-specific? | |
| 17:53:21 | sean-k-mooney | lbragstad: how woudl we tell which service called it? do you mean make ti depened on the event type | |
| 17:53:49 | gmann | is that mean the very original design of having multiple system and system_id in enforcement ? | |
| 17:54:03 | dansmith | sean-k-mooney: I think novaclient has an api for this, you just mean there's no CLI right? | |
| 17:54:03 | gmann | like system per service or so | |
| 17:54:20 | sean-k-mooney | dansmith: yes no cli but we likely have the python bindigns for it | |
| 17:54:26 | dansmith | yeah okay | |
| 17:54:40 | dansmith | no CLI makes sense while there's no CLI-able event I think | |
| 17:54:41 | sean-k-mooney | i would expect neutron to just deletagte to novaclinet internally | |
| 17:56:16 | lbragstad | sean-k-mooney does nova need to know which service called that API/ | |
| 17:56:29 | dansmith | no | |
| 17:56:40 | artom | Though currently only Neutron does, IIRC | |
| 17:56:47 | dansmith | it doesn't need to know that neutron only sends network events, but... that's kinda the point | |
| 17:56:49 | artom | And it's obvious that neutron does from the ebent name | |
| 17:57:03 | sean-k-mooney | artom: cinder and cyborg also call it | |
| 17:57:07 | dansmith | it's waiting for a thing, doesn't really need to know that neutron sent it, it just only really works if that's the case :) | |
| 17:57:27 | sean-k-mooney | artom: cinder for swap volume i think and cybrog for the arq binding completion | |
| 17:57:44 | artom | sean-k-mooney, I thought cinder swap volume was another "proper" API? | |
| 17:57:49 | artom | volume-update... | |
| 17:58:01 | sean-k-mooney | perhaps but there are cinder volume event | |
| 17:58:19 | sean-k-mooney | dansmith: so ya neutron is using cinder client https://github.com/openstack/neutron/blob/master/neutron/notifiers/nova.py#L84-L91 | |
| 17:58:26 | sean-k-mooney | *novaclient | |
| 17:58:27 | artom | Yeah https://docs.openstack.org/api-ref/compute/?expanded=update-a-volume-attachment-detail#update-a-volume-attachment | |
| 17:59:25 | sean-k-mooney | artom: it uses for volume extetnions not swap sorry | |
| 17:59:42 | artom | Anyways, we're off point here | |
| 18:00:02 | sean-k-mooney | artom: this is the list of events currently https://github.com/openstack/nova/blob/50fdbc752a9ca9c31488140ef2997ed59d861a41/nova/objects/external_event.py#L18-L36 | |
| 18:00:11 | dansmith | currently neutron is using a project token to send these, | |
| 18:00:30 | artom | "power-update" is weird | |
| 18:00:35 | artom | When/how does that happen? | |
| 18:01:02 | dansmith | is that because that's the token and client that neutron uses to interact with nova or other things in a sensible way, or just because it has no knowledge that a system scoped token would be right? | |
| 18:01:07 | dansmith | artom: ironic, IIRC | |
| 18:01:17 | dansmith | artom: it's not just neutron :) | |
| 18:01:59 | lbragstad | yeah - i think it's using the nova service user, which has the admin role | |
| 18:02:15 | lbragstad | and we haven't really gone through that migration yet, from a policy perspective | |
| 18:03:47 | dansmith | lbragstad: meaning it's just naive and not like that user/client is project-scoped for other stuff? | |
| 18:05:06 | dansmith | even still, if neutron is sending an event for an instance or group of ports or something, having it be project-scoped in that call to the event thing also helps to prevent any missteps in sending events to other instances | |
| 18:05:23 | dansmith | like if there was some port change thing going on, during ownership transfer, or anything else | |
| 18:05:43 | dansmith | this goes back to my "the interface is specific to project-scoped resources, so it feels like it too should be project-scoped" | |
| 18:07:24 | lbragstad | iiuc - it's using the nova service user, which just happens to have the admin role (probably for legacy reasons) and that's why it works | |
| 18:07:52 | lbragstad | so - because the nova user has the 'admin' role on the service project, it can update external server events for instance 'foo' in project bar... | |
| 18:07:53 | dansmith | yeah, well the default policy makes the api admin-only anyway | |
| 18:08:57 | sean-k-mooney | yes so its relyin gon haveing a user with admin rights | |
| 18:09:13 | sean-k-mooney | that can be the nova user or a common service user | |
| 18:09:14 | lbragstad | correct - but it's not enforcing tenancy in any way - from what i can tell | |
| 18:09:33 | sean-k-mooney | i dont think it is either today | |
| 18:09:59 | sean-k-mooney | since this is mainly a service to service api | |
| 18:10:04 | dansmith | the api? | |
| 18:11:44 | dansmith | it uses the context to look up the instances it creates the events for, so it should be scoped to the project of the token | |
| 18:11:48 | sean-k-mooney | the external events api does not assert that the user that created teh event is a has any relationship with the project reosuce that is being modified | |
| 18:12:00 | dansmith | or I guess if you're admin then it lets you see them all, but it should still be tight if you're not admin | |
| 18:12:32 | dansmith | you won't be able to look up instances you don't have access to, and you'll fail with a 404 I think | |
| 18:12:58 | sean-k-mooney | well this has been admin only for as long as i can rememebr it exsiting | |
| 18:13:02 | dansmith | or just not send those events, I guess, I'm not sure, but.. | |
| 18:13:22 | dansmith | sean-k-mooney: by default you mean :) | |
| 18:13:31 | sean-k-mooney | yes by default | |
| 18:13:36 | dansmith | I'm just saying I don't think that the api is not tenant-safe | |
| 18:14:08 | sean-k-mooney | well while you can get a responce form tha tapi when you do a post we dont supprot get request on it correct | |
| 18:14:21 | dansmith | there's nothing to get | |
| 18:14:24 | sean-k-mooney | and the info you get back is pretty limited in general | |
| 18:14:24 | dansmith | there's no persistence | |
| 18:14:40 | dansmith | I'm saying you can't POST events for instances you don't own | |
| 18:14:41 | sean-k-mooney | right so since it most a write only api | |
| 18:14:50 | dansmith | it is entirely write-only | |
| 18:14:50 | sean-k-mooney | sure you can | |
| 18:15:10 | gmann | dansmith: sean-k-mooney I remember the discussion of need of service specific role for such cross service API. system scope in this API was not concluded/discussed permission for this at the time of moving to new defaults. | |
| 18:15:12 | sean-k-mooney | well ok you saying if you change the policy to allow anyone call it | |
| 18:15:15 | sean-k-mooney | then it wont work | |
| 18:15:16 | dansmith | objects.InstanceList.get_by_filters( | |
| 18:15:16 | dansmith | cctxt, {'uuid': instance_uuids_by_cell[cell_uuid]}, | |
| 18:15:32 | dansmith | sean-k-mooney: this ^ will not work for instances you don't own if you are not admin | |
| 18:15:42 | gmann | either project scope or both or need service user specific role for such operation | |
| 18:15:52 | sean-k-mooney | do we have a db level check to enforce that | |
| 18:16:22 | dansmith | sean-k-mooney: that's how that interface works right? | |
| 18:16:35 | dansmith | I mean, it certainly was when the code was written :) | |
| 18:17:25 | sean-k-mooney | in the port bindign case the event are all submited as tyepically the nova user regradesss of who owns the port | |
| 18:17:33 | sean-k-mooney | dansmith: the user token is never used | |
| 18:17:57 | dansmith | ...right, as admin yes? | |
| 18:18:03 | sean-k-mooney | also even if it was the even it decupled form a user action | |
| 18:18:07 | sean-k-mooney | yes as admin | |
| 18:18:17 | dansmith | what are we arguing about again? | |
| 18:19:04 | sean-k-mooney | wether the resouce that is being evented on is own by the user/project assocated with teh keyton token used to send the event to nova i think | |
| 18:19:43 | sean-k-mooney | i kind of got confused by what you were saying would and would not work and im not sure you were following me either | |
| 18:20:18 | dansmith | https://github.com/openstack/nova/blob/7967ad78649a1f8d7ffc34ae28274ee89b0011cf/nova/db/main/api.py#L1413-L1416 | |
| 18:20:32 | dansmith | this ^ is where we enforce you can only see your own instances in the DB layer, if not admin | |