Hello Everyone, We had discussion today on RBAC open points on Heat. I tried to capture the key points in below etherpad - https://etherpad.opendev.org/p/rbac-zed-ptg#L100 We have not concluded on heat question and decided to continue the discussion next Tuesday 14:00 UTC. As meetpad did not work for many of attendees, we will use google meet for next discussion. Details: - Tuesday 3rd May 14:00 UTC - Video call: https://meet.google.com/gie-derw-eer - https://wiki.openstack.org/wiki/Consistent_and_Secure_Default_Policies_Popup... Agenda: - https://etherpad.opendev.org/p/rbac-zed-ptg#L100 -gmann ---- On Thu, 21 Apr 2022 01:28:35 -0500 Rabi Mishra <ramishra@redhat.com> wrote ----
On Sat, Apr 9, 2022 at 10:10 AM Ghanshyam Mann <gmann@ghanshyammann.com> wrote: Hello Everyone,
I tried to attend the RBAC-related sessions on various projects[i] but I am sure I might have missed a few of them. I am summarizing the RBAC discussion on what open questions were from the project side and what we discussed in TC PTG. Feel free to append the discussion you had in your project or any query you want TC to solve.
Current status: ------------------ * I have started this etherpad[ii] to track the status of this goal, please keep it up to date as you progress the work in your project.
Open question: ------------------ 1. heat create_stack API calling the mixed scope APIs (for example create flavor and create server). what is best scope for heat API so that we do not have any security leak. We have not concluded the solution yet as we need the heat team also join the discussion and agree on that. But we have a few possible solutions listed below:
** Heat accepts stack API with system scope *** This means a stack with system resources would require a system admin role => Need to check with services relying on Heat ** Heat assigns a project-scope role to the requester during a processing stack operation and uses this project scope credential to manage project resources ** Heat starts accepting the new header accepting the extra token (say SYSTEM_TOKEN) and uses that to create/interact the system-level resource like create flavor.
This is probably more complex than what we think:) I would expect keystone to provide full backward compatibility (i.e toggle off srbac), so that existing heat stacks in upgraded deploymentswork as before. As for the different options mentioned above, - IMO, heat assigning a project-scoped role to a user dynamically is probably out of consideration. - Introducing hacks in heat to switch tokens when creating/updating different resources of a stack (assuming we get multiple system/project scoped tokens with authentication) is also not a good idea either. Also the fact heat still relies on keystone trusts (used for long running tasks[1] and signaling) would make it complicated. Let's discuss in the next scheduled call. [1] https://github.com/openstack/heat/blob/master/heat/common/config.py#L130
2. How to isolate the host level attribute in GET APIs? (cinder and manila have the same issue). Cinder GET volume API response has the host information. One possible solution we discussed is to have a separate API to show the host information to the system user and the rest of the volume response to the project users only. This is similar to what we have in nova.
Then we have a few questions from the Tacker side, where tacker create_vnf API internally call heat create_stack and they are planning to make create_vnf API for non-admin users.
Direction on enabling the enforce scope by default ------------------------------------------------------------ As keystone, nova, and neutron are ready with the new RBAC, we wanted to enable the scope checks by default. But after seeing the lack of integration testing and the above mentioned open question (especially heat and any deployment project breaking) we decided to hold it. As the first step, we will migrate the tempest tests to the new RBAC and will enable the scope for these services in devstack. And based on the testing results we will decide on it. But after seeing the amount of work needed in Tempest and on the open question, I do not think we will be able to do it in the Zed cycle. Instead, we will target to enable the 'new defaults' by default.
We ran out of time in TC and will continue the discuss these in policy popup meetings. I will push the schedule to Ml.
[i] https://etherpad.opendev.org/p/rbac-zed-ptg [ii] https://etherpad.opendev.org/p/rbac-goal-tracking
-gmann
-- Regards,Rabi Mishra