[heat][rbac] Management of "system resources" with SRBAC enforced

Takashi Kajinami tkajinam at redhat.com
Wed Mar 9 05:46:21 UTC 2022


I've been working on updating policy rules in heat according to the latest
guideline for SRBAC implementation.

Based on the recent direction change[1], now only project users are allowed
to create project-based resources like instances or networks. I'm updating
policy rules in heat so that only project users can manage project resources
in Heat like stacks or resources.


However this change reveals one potential issue with system resources.

In heat there are some resource types like OS::Nova::Flavor or
which is allowed for only system users. (I'll call these resources as
"system resources" here)

Because heat uses user credentials to create resources in backend services,
if we require
project scope for stack/resource management then we are no longer able to
create these system
resources as part of stack. (*1)

There are some options I can think of at this moment.

1. Deprecate and remove all resources which require system scope
- This is most easy solution to be implemented
- This one has the biggest user impact

2. Use service credential for resource creation
- This might have smallest user impact
- This requires a relatively big change in heat's architecture, which I've
not yet evaluated.
- We need to determine the project scope role to be allowed to do system

3. Implement additional project-role in each service to allow creation via
stack creation.
- This would avoid user impact.
- requires work in multiple components.
- We need to determine the project scope role to be allowed to do system

I'm not quite sure which one would be the best. If I can ask for some
feedback about these options
(or any other new options) from heat's perspective and rbac's perspective
then it would be nice.

As of now, nova and neutron no longer allow creating system users to create
project resources,
so system users are no longer able to create stacks with project resources
like instances or networks
with default "new" policies.

Thank you,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220309/c4b1f704/attachment.htm>

More information about the openstack-discuss mailing list