Assistance Needed: Restricting User List API Access Based on Project Context
Hello openstack community, I am currently working on an OpenStack kolla ansible 2023.1. I have created a custom role " owner " Objective: Users with the owner role can only list users within their project. Avoid additional API calls for filtering users by project. Current Challenge: Using direct API calls, the list users API currently returns all users without any project-specific filtering. While additional API calls to the role_assignments endpoint can achieve the desired filtering, this approach is not efficient and doesn't restrict access at the API level. I am considering defining custom Keystone policies to achieve this restriction. However, I am unsure how to properly configure these policies to enforce project-specific access control effectively. Thanks in advance 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."
Greetings, I don't think you're going to get such filtering and querying with just custom policy. Essentially, this should ideally be done with lower level logic close to the database to enforce the view, as doing it in the API before returning the result set to the user is ultimately inefficient. Ironic has a similar concept where baremetal nodes lists are filtered, and the enforcement of that (as in the need) is identified in the API layer through policy, and the overall query to the database only returns the relevant list matching the user's project. It was actually really simple for us to implement in ironic, but is definitely some code deep down in the stack. -Julia On Thu, Jul 11, 2024 at 11:34 AM Thamanna Farhath <thamanna.f@zybisys.com> wrote:
Hello openstack community, I am currently working on an OpenStack kolla ansible 2023.1. I have created a custom role " owner "
*Objective:*
1. Users with the owner role can only list users within their project. 2. Avoid additional API calls for filtering users by project.
*Current Challenge:* Using direct API calls, the list users API currently returns all users without any project-specific filtering. While additional API calls to the role_assignments endpoint can achieve the desired filtering, this approach is not efficient and doesn't restrict access at the API level.
I am considering defining custom Keystone policies to achieve this restriction. However, I am unsure how to properly configure these policies to enforce project-specific access control effectively.
Thanks in advance
------------------------------ *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."*
participants (2)
-
Julia Kreger
-
Thamanna Farhath