Open Stack

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 at 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 at 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 at 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 at 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/user-id-based-policy-enforcement.html
> >
> > 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"
> >  >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220207/8429d489/attachment.htm>