---- On Mon, 07 Feb 2022 12:08:36 -0600 Massimo Sgaravatto <massimo.sgaravatto@gmail.com> wrote ----
Ok, now I remember the discussion.So: - I am aware that support for user_id is implemented only for destructive operations- I am aware that such support will be removed Indeed in my policy files I am listing only destructive operations, apart from this resume operation (I can't remember why it is there). And I was wrong when I said that the support for user_id for resume worked in Train.I have just double checked and it seems to me that there is just a different behavior: - In Train if you have: "os_compute_api:os-suspend-server:resume": "rule:admin_api or user_id:%(user_id)s",
you are able to resume your instance but you are able also to resume instances owned by other users of the same project - In Xena if you have: "os_compute_api:os-suspend-server:resume": "rule:admin_api or user_id:%(user_id)s"
you are not even able to resume your instances
In train, we were not even passing the server's project_id as target to oslo policy and after that we started passign it so that admin or owner or server (owner means any user in that project) can be allowed - https://github.com/openstack/nova/blob/stable/ussuri/nova/api/openstack/comp...
So:1: I am going to remove the user_id based policy for the resume operation in the policy file
+1. -gmann 2: I personally don't really need to have issue #1960247 addressed3: Sorry for the noise !
Cheers, Massimo On Mon, Feb 7, 2022 at 6:32 PM Sean Mooney <smooney@redhat.com> wrote: On Mon, 2022-02-07 at 11:10 -0600, Ghanshyam Mann wrote:
---- On Mon, 07 Feb 2022 11:06:06 -0600 Massimo Sgaravatto <massimo.sgaravatto@gmail.com> wrote ----
Thanks Actually in the past support for user_id in the resume operation worked as expectedE.g. I have a train installation where I defined this rule in the policy.json file: "os_compute_api:os-suspend-server:suspend": "rule:admin_api or user_id:%(user_id)s",
and it works Cheers, Massimo
On Mon, Feb 7, 2022 at 5:03 PM Takashi Kajinami <tkajinam@redhat.com> wrote: Quickly checking the current code, it seems support for user_id was introduced to only suspend api[1] [1] https://review.opendev.org/c/openstack/nova/+/353344 I've opened a bug for nova[2] because supporting consistent rules for suspend and resumemakes clear sense to me. [2] https://bugs.launchpad.net/nova/+bug/1960247
On Tue, Feb 8, 2022 at 12:25 AM Massimo Sgaravatto <massimo.sgaravatto@gmail.com> wrote: Dear all
I am running a Xena installation I have modified the nova policy fail so that certain operations can be done only by the user who created the instance, or by the administratorThis [*] is my policy.yaml file.While the suspend operation works as intended (I can suspend only my instances and I am not allowed to suspend an instance created by another user) I am not able to resume an instance that I own and that I have previously suspended.I get this error: ERROR (Forbidden): Policy doesn't allow os_compute_api:os-suspend-server:suspend to be performed. (HTTP 403) (Request-ID: req-c57458bc-b1ea-4b40-a1d2-0f67608ef673)
Only removing the line: "os_compute_api:os-suspend-server:suspend": "rule:admin_api or user_id:%(user_id)s" from the policy file, I am able to resume the instance. I am not able to understand what is wrong with that policy. Any hints ?
I think we had the same conversation in June 2020 also[1].
Nova does not restrict the policy by user_id except keypairs API. We have kept it for a few of the destructive actions (for backwards compatibility) and intent to remove them too in future. I remember we discussed this in 2016 but I could not find the ML thread for that but the consensus that time was we do not intend to support user_id based restriction permission in the API.
This is the spec where we kept the user_id support for destructive actions and the reason.
https://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/us...
As we are moving our policy to new defaults (with new direction), after that we should discuss to remove all the user_id enforcement support except keypair. But defiantly should not extend it for any other action.
[1] http://lists.openstack.org/pipermail/openstack-discuss/2020-June/015273.html
thanks i had forgot about that spec entirly. i have marked the bug as opinion and whistlist https://bugs.launchpad.net/nova/+bug/1960247 we can continue to disucss it but i think we would need to come to a concenus about this and given the previous spec likely treat this as a spec/feature not a bug. we certenly woudl have to consider how this woudl work with secure rbac and if this aligns with the project direction as a whole.
-gmann
Thanks, Massimo
[*] # Pause a server # POST /servers/{server_id}/action (pause) # Intended scope(s): system, project "os_compute_api:os-pause-server:pause": "rule:admin_api or user_id:%(user_id)s"
# Delete a server # DELETE /servers/{server_id} # Intended scope(s): system, project "os_compute_api:servers:delete": "rule:admin_api or user_id:%(user_id)s"
# Resize a server # POST /servers/{server_id}/action (resize) # Intended scope(s): system, project "os_compute_api:servers:resize": "rule:admin_api or user_id:%(user_id)s"
# Rebuild a server # POST /servers/{server_id}/action (rebuild) # Intended scope(s): system, project "os_compute_api:servers:rebuild": "rule:admin_api or user_id:%(user_id)s"
# Stop a server # POST /servers/{server_id}/action (os-stop) # Intended scope(s): system, project "os_compute_api:servers:stop": "rule:admin_api or user_id:%(user_id)s"
# Resume suspended server # POST /servers/{server_id}/action (resume) # Intended scope(s): system, project "os_compute_api:os-suspend-server:resume": "rule:admin_api or user_id:%(user_id)s"
# Suspend server # POST /servers/{server_id}/action (suspend) # Intended scope(s): system, project "os_compute_api:os-suspend-server:suspend": "rule:admin_api or user_id:%(user_id)s"