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. 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