Open Stack

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 deployments
work 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220421/bb813a64/attachment.htm>