Open Stack

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_Team#Meeting

Agenda:
- https://etherpad.opendev.org/p/rbac-zed-ptg#L100

-gmann 

 ---- On Thu, 21 Apr 2022 01:28:35 -0500 Rabi Mishra <ramishra at redhat.com> wrote ----
 > 
 > 
 > On Sat, Apr 9, 2022 at 10:10 AM Ghanshyam Mann <gmann at 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
 >