[nova][ops] Problem with nova policies for resume operation
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 administrator This [*] 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 ? 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"
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 resume makes 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:
Thanks Actually in the past support for user_id in the resume operation worked as expected E.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:
---- On Mon, 07 Feb 2022 11:06:06 -0600 Massimo Sgaravatto <massimo.sgaravatto@gmail.com> wrote ----
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 -gmann
---- On Mon, 07 Feb 2022 11:10:37 -0600 Ghanshyam Mann <gmann@ghanshyammann.com> wrote ----
And as long as your user belong to same project instance is booted for then you should be able to resume instance by any user of that project even you suspended it with other user of same project and user_id policy enmforcement in suspend policy. Or you suspended server with user of other project and trying to resume by other project? -gmann
On Mon, 2022-02-07 at 11:10 -0600, Ghanshyam Mann wrote:
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.
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 So: 1: I am going to remove the user_id based policy for the resume operation in the policy file 2: I personally don't really need to have issue #1960247 addressed 3: Sorry for the noise ! Cheers, Massimo On Mon, Feb 7, 2022 at 6:32 PM Sean Mooney <smooney@redhat.com> wrote:
---- On Mon, 07 Feb 2022 12:08:36 -0600 Massimo Sgaravatto <massimo.sgaravatto@gmail.com> wrote ----
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 !
On Mon, 2022-02-07 at 18:06 +0100, Massimo Sgaravatto wrote:
os_compute_api:os-suspend-server:suspend only covers suppend os_compute_api:os-suspend-server:resume applies to resume. this was also the case in train by the way. technially upstream does not "support" custom policy in that if you use custom policy and a feature is missing like passing user_id to a specifc policy check its not a bug this a feature request. however you can make the consitency arguemnt that takashi has made in https://bugs.launchpad.net/nova/+bug/1960247 to position it as a bug. technially the set of varible that are aviale however are not defined as part of the api so you should not assume user_id is always avaiable. usering custom policy shoudl also be done sparingly. for a private cloud this is fine but it woudl be an interoperablity issue to do this in a public cloud. server are own by projects not users so we woudl expect anyone in the porjec to be able to suspend or resume it in a could by default. you obviously have other requirements which is fine and why we support custom policy but this is really a feature request. its a trivial one for the most part and we may consider trating this as a bug but i think we would have to dicuss this at the nova team meeting before agreeing to trat this as a backportable bugfix rather then a new feature. i have triaged the bug as whishlist for now.
participants (4)
-
Ghanshyam Mann
-
Massimo Sgaravatto
-
Sean Mooney
-
Takashi Kajinami