<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Apr 9, 2022 at 10:10 AM Ghanshyam Mann <<a href="mailto:gmann@ghanshyammann.com">gmann@ghanshyammann.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello Everyone,<br>
<br>
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<br>
the RBAC discussion on what open questions were from the project side and what we discussed in TC PTG. Feel free to append <br>
the discussion you had in your project or any query you want TC to solve.<br>
<br>
Current status:<br>
------------------<br>
* 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.<br>
<br>
Open question:<br>
------------------<br>
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<br>
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.<br>
But we have a few possible solutions listed below:<br>
<br>
** Heat accepts stack API with system scope<br>
*** This means a stack with system resources would require a system admin role => Need to check with services relying on Heat<br>
** Heat assigns a project-scope role to the requester during a processing stack operation and uses this project scope credential to manage project resources<br>
** 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.<br></blockquote><div><br></div><div>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 deployments</div><div>work as before. As for the different options mentioned above,</div><div><br></div><div><div>- IMO, heat assigning a project-scoped role to a user dynamically is probably out of consideration. <br></div><div>- 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</div><div>  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.</div><div><br></div>Let's discuss in the next scheduled call.</div><div><br></div><div><div>[1] <a href="https://github.com/openstack/heat/blob/master/heat/common/config.py#L130">https://github.com/openstack/heat/blob/master/heat/common/config.py#L130</a></div></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
2. How to isolate the host level attribute in GET APIs? (cinder and manila have the same issue). Cinder GET volume API response has<br>
the host information. One possible solution we discussed is to have a separate API to show the host information to the system user and<br>
the rest of the volume response to the project users only. This is similar to what we have in nova.<br>
<br>
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<br>
make create_vnf API for non-admin users.<br>
<br>
Direction on enabling the enforce scope by default<br>
------------------------------------------------------------<br>
As keystone, nova, and neutron are ready with the new RBAC, we wanted to enable the scope checks by default. But after seeing the<br>
lack of integration testing and the above mentioned open question (especially heat and any deployment project breaking) we decided to hold<br>
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<br>
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<br>
to do it in the Zed cycle. Instead, we will target to enable the 'new defaults' by default. <br>
<br>
We ran out of time in TC and will continue the discuss these in policy popup meetings. I will push the schedule to Ml.<br>
<br>
[i] <a href="https://etherpad.opendev.org/p/rbac-zed-ptg" rel="noreferrer" target="_blank">https://etherpad.opendev.org/p/rbac-zed-ptg</a><br>
[ii] <a href="https://etherpad.opendev.org/p/rbac-goal-tracking" rel="noreferrer" target="_blank">https://etherpad.opendev.org/p/rbac-goal-tracking</a><br>
<br>
-gmann<br>
<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Regards,</div>Rabi Mishra<div><br></div></div></div></div></div></div>