Hi, Thanks for the responses so far. Nova: Using GET /servers/detail?all_tenants=1&id=<uuid> works with our custom admin_instance_read role — appreciate the suggestion. However, other instance-level actions (pause, resume, delete, etc.) still fail with 404 unless the admin role is used, even when the instance is visible. Is there any way to relax these checks for trusted custom roles? We understand from earlier messages that this behavior is due to hardcoded DB-layer restrictions or missing full RBAC scope evaluations.  Neutron: With the admin_network_read role assigned to a system-level user, we are still unable to list or access all networks across projects (including shared/external). As mentioned by @, it appears that database-level filters in Neutron are still restricting visibility. We've looked at the suggested line here: https://github.com/openstack/neutron-lib/blob/fd011c9/neutron_lib/db/model_q... Is there a workaround or patch available to bypass this, or should we wait for a fix as per Bug #2115184? We’re trying to delegate operational tasks without assigning full admin rights, so fine-grained RBAC is essential. Thanks, Thamanna Farhath ---- On Mon, 23 Jun 2025 14:26:55 +0530 Sławek Kapłoński <skaplons@redhat.com> wrote --- Hi, Dnia piątek, 13 czerwca 2025 09:31:50 czas środkowoeuropejski letni Sławek Kapłoński pisze:

Hi,

From a quick look at Neutron and "get_network" policy it seems for me that this is not really filtered out on the API policy level but when data is fetched from the database, exactly in https://github.com/openstack/neutron-lib/blob/fd011c955dfae1072555c69b6ba742... I think that you should open LP bug for Neutron for this. I will try to look deeper into it when I will have some time.

I've just opened bug regarding this for Neutron: https://bugs.launchpad.net/neutron/+bug/2115184 and I will try to take a look at it in next days.

Dnia piątek, 13 czerwca 2025 07:04:29 czas środkowoeuropejski letni Thamanna Farhath pisze:

...

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.

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.

Thanks & Regards

Thamanna Farhath N

Associate engineer - R&D

Zybisys IT consulting Disclaimer : The content of this email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error, please notify the sender and remove the messages from your system. If you are not the named addressee, it is strictly forbidden for you to share, circulate, distribute or copy any part of this e-mail to any third party without the written consent of the sender.

E-mail transmission cannot be guaranteed to be secured or error free as information could be intercepted, corrupted, lost, destroyed, arrive late, incomplete, or may contain viruses. Therefore, we do not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email."

-- Slawek Kaplonski Principal Software Engineer Red Hat

-- Slawek Kaplonski Principal Software Engineer Red Hat Disclaimer : The content of this email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error, please notify the sender and remove the messages from your system. If you are not the named addressee, it is strictly forbidden for you to share, circulate, distribute or copy any part of this e-mail to any third party without the written consent of the sender. E-mail transmission cannot be guaranteed to be secured or error free as information could be intercepted, corrupted, lost, destroyed, arrive late, incomplete, or may contain viruses. Therefore, we do not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email."

On 24/06/2025 14:08, Sławek Kapłoński wrote:

Hi,

Dnia wtorek, 24 czerwca 2025 14:48:55 czas środkowoeuropejski letni Thamanna Farhath pisze:

...

Hi,

Thanks for the responses so far.

Nova:

Using GET /servers/detail?all_tenants=1&id=<uuid> works with our custom admin_instance_read role — appreciate the suggestion.

However, other instance-level actions (pause, resume, delete, etc.) still fail with 404 unless the admin role is used, even when the instance is visible. Is there any way to relax these checks for trusted custom roles?

We understand from earlier messages that this behavior is due to hardcoded DB-layer restrictions or missing full RBAC scope evaluations.

Neutron:

With the admin_network_read role assigned to a system-level user, we are still unable to list or access all networks across projects (including shared/external). as far as i am aware networks are considered project scooped reosorces so then shoudl never be visable to a system scoped token even with custom policy.

As mentioned by @, it appears that database-level filters in Neutron are still restricting visibility. We've looked at the suggested line here:

https://github.com/openstack/neutron-lib/blob/fd011c9/neutron_lib/db/model_q...

Is there a workaround or patch available to bypass this, or should we wait for a fix as per Bug #2115184? Nope, there is no workaround nor patch proposed yet. i would argue that it probaly should not be considerd a bug assuming when they say "system-level user" they actully mean a user with a system scoped token.

...

We’re trying to delegate operational tasks without assigning full admin rights, so fine-grained RBAC is essential.

Thanks,

Thamanna Farhath

---- On Mon, 23 Jun 2025 14:26:55 +0530 Sławek Kapłoński <skaplons@redhat.com> wrote ---

Hi,

Dnia piątek, 13 czerwca 2025 09:31:50 czas środkowoeuropejski letni Sławek Kapłoński pisze:

...

Hi,

From a quick look at Neutron and "get_network" policy it seems for me that this is not really filtered out on the API policy level but when data is fetched from the database, exactly in https://github.com/openstack/neutron-lib/blob/fd011c955dfae1072555c69b6ba742... I think that you should open LP bug for Neutron for this. I will try to look deeper into it when I will have some time.

I've just opened bug regarding this for Neutron: https://bugs.launchpad.net/neutron/+bug/2115184 and I will try to take a look at it in next days.

...

Dnia piątek, 13 czerwca 2025 07:04:29 czas środkowoeuropejski letni Thamanna Farhath pisze:

...

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.

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.

Thanks & Regards

Thamanna Farhath N

Associate engineer - R&D

Zybisys IT consulting Disclaimer : The content of this email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error, please notify the sender and remove the messages from your system. If you are not the named addressee, it is strictly forbidden for you to share, circulate, distribute or copy any part of this e-mail to any third party without the written consent of the sender.

E-mail transmission cannot be guaranteed to be secured or error free as information could be intercepted, corrupted, lost, destroyed, arrive late, incomplete, or may contain viruses. Therefore, we do not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email."

-- Slawek Kaplonski Principal Software Engineer Red Hat

-- Slawek Kaplonski Principal Software Engineer Red Hat Disclaimer : The content of this email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error, please notify the sender and remove the messages from your system. If you are not the named addressee, it is strictly forbidden for you to share, circulate, distribute or copy any part of this e-mail to any third party without the written consent of the sender.

E-mail transmission cannot be guaranteed to be secured or error free as information could be intercepted, corrupted, lost, destroyed, arrive late, incomplete, or may contain viruses. Therefore, we do not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email."

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? Thanks & regards, Thamanna Farhath ---- On Sat, 14 Jun 2025 00:20:34 +0530 Ghanshyam Maan <gmaan@ghanshyammann.com> wrote --- ---- On Thu, 12 Jun 2025 22:04:29 -0700 Thamanna Farhath < mailto: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."

Disclaimer : The content of this email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error, please notify the sender and remove the messages from your system. If you are not the named addressee, it is strictly forbidden for you to share, circulate, distribute or copy any part of this e-mail to any third party without the written consent of the sender. E-mail transmission cannot be guaranteed to be secured or error free as information could be intercepted, corrupted, lost, destroyed, arrive late, incomplete, or may contain viruses. Therefore, we do not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email."

Hi  mailto:gmaan@ghanshyammann.com , Thank you for your input. Could you please suggest any other options to achieve my scenario? ---- On Thu, 19 Jun 2025 01:02:15 +0530 Ghanshyam Maan <gmaan@ghanshyammann.com> wrote --- ---- On Tue, 17 Jun 2025 00:59:22 -0700 Thamanna Farhath < mailto: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. -gmaan

Thanks & regards,

Thamanna Farhath

---- On Sat, 14 Jun 2025 00:20:34 +0530 Ghanshyam Maan < mailto: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 < mailto: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."

Disclaimer : The content of this email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error, please notify the sender and remove the messages from your system. If you are not the named addressee, it is strictly forbidden for you to share, circulate, distribute or copy any part of this e-mail to any third party without the written consent of the sender. E-mail transmission cannot be guaranteed to be secured or error free as information could be intercepted, corrupted, lost, destroyed, arrive late, incomplete, or may contain viruses. Therefore, we do not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email."

Hi, That said, I agree with your observation. In our case, we're actually facing similar issues not just with GET /servers/{id}, but also with several other instance-level actions such as pause, resume, edit instance, and delete instance. These operations also fail unless the admin role is present, even though our goal is to delegate these permissions to a custom scoped role for operational tasks. To address this, we're planning to restrict full admin privileges and instead define fine-grained roles for specific activities. Error: {     "itemNotFound": {         "code": 404,         "message": "Instance {id} could not be found."     } } Thamanna Farhath   Associate Engineer R&D  mailto:manoj.kumar@zybisys.com thamanna.f@zybisys.com https://www.zybisys.com     https://www.linkedin.com/company/zybisys    https://www.facebook.com/Zybisys    https://www.instagram.com/zybisys    https://www.youtube.com/@zybisys https://www.facebook.com/Zybisys/ ---- On Thu, 19 Jun 2025 16:04:40 +0530 Andriy Kurilin <andr.kurilin@gmail.com> wrote --- hi all! ср, 18 черв. 2025 р. о 21:32 Ghanshyam Maan < mailto:gmaan@ghanshyammann.com > пише:  ---- On Tue, 17 Jun 2025 00:59:22 -0700  Thamanna Farhath < mailto: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 :)   -gmaan  >  > Thanks & regards,  >  > Thamanna Farhath  >  >  > ---- On Sat, 14 Jun 2025 00:20:34 +0530 Ghanshyam Maan < mailto: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 < mailto: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. Disclaimer : The content of this email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error, please notify the sender and remove the messages from your system. If you are not the named addressee, it is strictly forbidden for you to share, circulate, distribute or copy any part of this e-mail to any third party without the written consent of the sender. E-mail transmission cannot be guaranteed to be secured or error free as information could be intercepted, corrupted, lost, destroyed, arrive late, incomplete, or may contain viruses. Therefore, we do not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email."

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-rba... 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.

чт, 19 черв. 2025 р. о 14:07 Sean Mooney <smooney@redhat.com> пише:

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-rba... 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.

This sounds like something that ideally should be handled at the `nova.compute.api.API` level. That said, would you be open to aligning with best practices from the servers list API - specifically, elevating context when the user passes the servers:detail:all_tenants policy? Something like https://review.opendev.org/c/openstack/nova/+/952896 Would this be considered a low-impact API change, since it reuses already established logic? Or would it require a blueprint, broader discussion, a separate API microversion?

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.

The CLI does not support this filter, and even if it did, such behavior would break the expected user flow - i.e., users expect it to work with 'openstack server show'.

...

-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.

-- Best regards, Andriy Kurilin.

---- On Fri, 20 Jun 2025 06:13:08 -0700 Sean Mooney <smooney@redhat.com> wrote ---

On 20/06/2025 13:17, Andriy Kurilin wrote:

...

This sounds like something that ideally should be handled at the `nova.compute.api.API` level. That said, would you be open to aligning with best practices from the servers list API - specifically, elevating context when the user passes the |servers:detail:all_tenants| policy? Something like https://review.opendev.org/c/openstack/nova/+/952896

Would this be considered a low-impact API change, since it reuses already established logic? Or would it require a blueprint, broader discussion, a separate API microversion?

so this is a grey area

techinally all api change requrie a spec but we don tgenerally consider policy chagne to be api changes.

here you care not intoducting a new poilicy you are just applying it to an addtional endpoint.

list vs show.

if you were suggesting adding ajn all_tenatns query arg (which you are not) that woudl require a new api microversion.

issues related to using custom policy are only consider upstream bugs if they also happen with default policy, i.e. if this was broken for an admin then it woudl be a bug but if its only broken for your custom role its not. This would be a blueprint not a bug as a result but im unsure if we would require a spec or not for this specific case. If you wanted to do this more broadly i think we would want a spec to describe all the rest api impact and fully assess what if any upgrade impact those change would have and the possible security implications.

if you want to get more guidance on that i woudl suggest rasign it at next week irc meeting or seeing if others responed

I spent some time by checking history when it was made configurable for list APIs and not for Show (12 years back https://review.opendev.org/c/openstack/nova/+/16160) and why we should not enable it now for server show API. I could not find a solid reason not to do. Considering the below factors, I do not consider this a spec/microversion bump requried API change: * Backward compatibility: OK New policy default to 'Admin' keep it backward compatible. - With default policies (new policy default to Admin), nothing changed here for existing use case where admin query other projects or project query their own instance. - If anyone overridden 'servers:show' policy then it continue working same way for the above use case. new policy is not in effect for existing use cases. - There is difference in response from list detail vs show API so we are not going to expose any new info to non-admin users which they can do currently. I am ok to fix this as a bug fix but as Sean mentioned, let's put this in next week IRC meeting agenad to get more opinion on this. One thing I commented below about achieving the same via list detail and knowing why user do not want to do that can be a good things to consider this a bug fix.

...

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.

The CLI does not support this filter, and even if it did, such behavior would break the expected user flow - i.e., users expect it to work with 'openstack server show'.

You can do this withbelow args in CLI, that will give the server detail of specified server from oterhr project. This is the common way to list single server from other project. "openstack server list --all-projects --project <project>" - https://docs.openstack.org/python-openstackclient/latest/cli/command-objects... Can you check if that works for user or if they want to do it with 'openstack server show' only then it will be good to know the reason and use case for that which can be a conviencing factor to add this ability in server show API also. This is something I would like to know to consider it a worth bug fix or we leave it as it is because there is way to do via other API. -gmaan

right so there you kind of hinting a fundamental mismatch between what the goals of the cli are and your goals in general we do not encourage operators to modify policy at all from upstream.

custom policy is support because we know in some environment it safe to allow some operation to have a difent policy then upstream each time you do that, you create an interop and documentation problem for users of your cloud but if an entirly private cloud that can be ok. on the tooling side the clinets are not allowed to have arguments that only work with non default policy alhtough they are alowed ot suprpot admin only apis. semantically the client shoudl call the show api not the list api when you do server show so osc is doign the corect thing today.

i provided this example because if your going to hevialy customerise your api policy you shoudl not expect to be abel to fully use those customization via horizon or the openstack client without writing your own plugings.