On 19/06/2025 11:34, Andriy Kurilin wrote:
> hi all!
>
> ср, 18 черв. 2025 р. о 21:32 Ghanshyam Maan <gmaan@ghanshyammann.com>
> пише:
>
>      ---- On Tue, 17 Jun 2025 00:59:22 -0700  Thamanna Farhath
>     <thamanna.f@zybisys.com> wrote ---
>      > Hi Ghanshyam,
>      >
>      > Thanks for your input.
>      >
>      > I’ve created a custom role (admin_instance_read) to allow
>     listing instances across all projects without using the admin
>     role. Listing works fine using policies like:
>      >
>      > Option 1:
>      > "os_compute_api:servers:index:get_all_tenants":
>     "role:admin_instance_read"
>      > "os_compute_api:servers:detail:get_all_tenants":
>     "role:admin_instance_read"
>      > Option 2:
>      > "admin_or_admin_instance_read": "role:admin or
>     role:admin_instance_read""os_compute_api:servers:index:get_all_tenants":
>     "rule:admin_or_admin_instance_read""os_compute_api:servers:detail:get_all_tenants":
>     "rule:admin_or_admin_instance_read"
>      > Option 3:
>      > "os_compute_api:servers:index:get_all_tenants":
>     "rule:context_is_admin or
>     role:admin_instance_read""os_compute_api:servers:detail:get_all_tenants":
>     "rule:context_is_admin or role:admin_instance_read"
>      > In all three cases:
>      >
>      > Listing instances (GET /servers?all_tenants=1) works fine.
>      >
>      >
>      > Getting instance details or performing actions fails with 404
>     unless the user has the admin role.
>      >
>      >
>      > {  "itemNotFound": {    "code": 404,    "message": "Instance
>     <uuid> could not be found."  }}
>      > Is there an additional policy or workaround needed to allow
>     full cross-project access for custom roles?
>
>     That is exxpected behavior. Nova allow non-admin (if policy
>     overriden) only to list/list-detail instances across projects. Any
>     other
>     operation on instances are restricted to owner (user within same
>     project) or admin only.
>
> I completely understand and agree with enforcing strict validation to
> ensure only admins can modify workloads across projects. However, I'm
> curious about the reasoning behind restricting read operations -
> specifically the GET /servers/{id} API.
>
> What are the concerns that prevent using the same policy (i.e.,
> `os_compute_api:servers:index:get_all_tenants`) for server detail
> retrieval? Functionally, it seems similar to listing servers with a
> UUID filter.
>
> We’re working on integrating OpenStack with third-party systems (audit
> for example). While servers list API seems enough, debugging for a
> particular server status looks far from ideal :)

that proably coudl be afely relaxed the reall reason it has not been in
orginaly this enforcement was done in the db layer in many places as
policy was not configurable at all.

when we started movign to a more configurable approch and workign on the
https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html
transtation

we needed to keep some of the db chaeck in case you were runnign in
legacy mode (not using the new policy defaults) and other we keep out of
paranoia because

we did nto have time to fully audit the code path to ensure there was no
way to incorrectly by pass the check is you guessed the uuid of someone
else instance,


not that before enable the new defaults there was no concept of read
only access.
if you had any role on a project you had read write access.
so if you had that "reader" role but the admin had not enabled the new
polciy default you actully had read write becuase under the
legacy scheme openstack in general only check too things. are you admin
or does the token have a role in the project.
the rest was done at the db layer not the policy layer.

so to answer your question maninly because no one has done the work to
prove that the other api calls are safe.

you can work aroudn this by doing a server detail list with uuid=<vm
uuid> and that will effectivly be the same as server show.

it will also be almost as efficient at the db level too.

>
>     -gmaan
>
>      >
>      > Thanks & regards,
>      >
>      > Thamanna Farhath
>      >
>      >
>      > ---- On Sat, 14 Jun 2025 00:20:34 +0530 Ghanshyam Maan
>     <gmaan@ghanshyammann.com> wrote ---
>      >
>      >
>      >
>      >
>      >
>      > Disclaimer :  The content of this email and anyfiles
>     transmitted with it are confidential and intended solely for the
>     use ofthe individual or entity to which they are addressed. If you
>     have received thisemail in error, please notify the sender and
>     remove the messages from yoursystem. If you are not the named
>     addressee, it is strictly forbidden for you toshare, circulate,
>     distribute or copy any part of this e-mail to any third
>     partywithout the written consent of the sender.
>      >
>      >
>      > E-mail transmission cannot be guaranteed to besecured or error
>     free as information could be intercepted, corrupted,
>     lost,destroyed, arrive late, incomplete, or may contain viruses.
>     Therefore, we donot accept liability for any errors or omissions
>     in the contents of thismessage, which arise as a result of e-mail
>     transmission. The recipient shouldcheck this e-mail and any
>     attachments for the presence of viruses. The companyaccepts no
>     liability for any damage caused by any virus transmitted by
>     thisemail."
>      >
>      >
>      > ---- On Thu, 12 Jun 2025 22:04:29 -0700  Thamanna Farhath
>     <thamanna.f@zybisys.com> wrote ---
>      >  > Hi Team,
>      >  >
>      >  > As part of enhancing our OpenStack RBAC policy management,
>     we are in the process of setting up custom roles for various
>     admin-related activities.
>      >  >
>      >  > Custom Roles Used:
>     admin_instance_read,admin_volume_read,admin_network_read,admin_glance_read
>
>      >  > Policy Customizations:
>      >  >
>      >  > # Compute - List all instances across
>     tenants"os_compute_api:servers:index:get_all_tenants":
>     "rule:context_is_admin or
>     role:admin_instance_read""os_compute_api:servers:detail:get_all_tenants":
>     "rule:context_is_admin or role:admin_instance_read"# Network - Get
>     networks (shared/external/own project)"get_network":
>     "(rule:admin_only) or (role:reader and project_id:%(project_id)s)
>     or rule:shared or rule:external or rule:context_is_advsvc or
>     role:admin_network_read"# Volume - List all volumes and snapshots
>     across projects"volume:get_all":
>     "rule:xena_system_admin_or_project_reader or
>     role:admin_volume_read""volume:get_all_snapshots":
>     "rule:xena_system_admin_or_project_reader or
>     role:admin_volume_read"# Image - List all images including
>     shared/community/public"get_image": "role:admin or (role:reader
>     and project_id:%(project_id)s) or project_id:%(member_id)s or
>     'community':%(visibility)s or 'public':%(visibility)s or
>     'shared':%(visibility)s or role:admin_glance_read""get_images":
>     "role:admin or (role:reader and project_id:%(project_id)s) or
>     role:admin_glance_read"
>      >  > Issue:
>      >  >
>      >  > Despite the above configurations, listing all instances,
>     images, volumes, and networks across all projects still only works
>     for the admin role. The custom roles (e.g., admin_instance_read,
>     etc.) are not taking effect for cross-project visibility as expected.
>      >  >
>      >
>      > What error or instances list do you get for
>     'admin_instance_read' ?
>      >
>      > If policy is allowed as per customer override, then compute
>     allowsthe  user to list cross-project instances but I will
>      > suggest to remove the admin access from policy and try how it
>     behaves:
>      >
>      > # Compute - List all instances across tenants
>      > "os_compute_api:servers:index:get_all_tenants":
>     "role:admin_instance_read"
>      > "os_compute_api:servers:detail:get_all_tenants":
>     "role:admin_instance_read"
>      >
>      >  > Request:
>      >  >
>      >  > I would appreciate any suggestions or insights on:
>      >  >
>      >  > Whether additional policy bindings or role scopes are required.
>      >  >
>      >  >
>      >  > If any service-specific constraints might be overriding the
>     custom roles.
>      >  >
>      >  >
>      >  > Any known limitations regarding get_all_tenants behavior
>     with custom roles.
>      >
>      > Can you list the command/API you are trying to list all instance?
>      >
>      > In compute, along with project-id filter you need to pass
>     '--all-tenants' filter also, otherwise nova will always
>      > return requested user instances only.
>      >
>      > -gmaan
>      >
>      >  >
>      >  >
>      >  >
>      >  >
>      >  > Thanks & Regards
>      >  > Thamanna Farhath N
>      >  > Associate engineer - R&D
>      >  > Zybisys IT consulting
>      >  >
>      >  >
>      >  >
>      >  > Disclaimer :  The content of this email and anyfiles
>     transmitted with it are confidential and intended solely for the
>     use ofthe individual or entity to which they are addressed. If you
>     have received thisemail in error, please notify the sender and
>     remove the messages from yoursystem. If you are not the named
>     addressee, it is strictly forbidden for you toshare, circulate,
>     distribute or copy any part of this e-mail to any third
>     partywithout the written consent of the sender.
>      >  >
>      >  >
>      >  > E-mail transmission cannot be guaranteed to besecured or
>     error free as information could be intercepted, corrupted,
>     lost,destroyed, arrive late, incomplete, or may contain viruses.
>     Therefore, we donot accept liability for any errors or omissions
>     in the contents of thismessage, which arise as a result of e-mail
>     transmission. The recipient shouldcheck this e-mail and any
>     attachments for the presence of viruses. The companyaccepts no
>     liability for any damage caused by any virus transmitted by
>     thisemail."
>      >  >
>      >  >
>      >  >
>      >
>      >
>
>
>
> --
> Best regards,
> Andriy Kurilin.