[tc][all][ Zed Virtual PTG RBAC discussions Summary
gmann at ghanshyammann.com
Tue Apr 26 18:59:04 UTC 2022
We had discussion today on RBAC open points on Heat. I tried to capture the key points in below etherpad
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.
- Tuesday 3rd May 14:00 UTC
- Video call: https://meet.google.com/gie-derw-eer
---- 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 and signaling) would make it complicated.
> Let's discuss in the next scheduled call.
>  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
> Regards,Rabi Mishra
More information about the openstack-discuss