<div dir="ltr"><div>Hello,</div><div><br></div><div><br></div><div>I've been working on updating policy rules in heat according to the latest</div><div>guideline for SRBAC implementation.</div><div><br></div><div>Based on the recent direction change[1], now only project users are allowed</div><div>to create project-based resources like instances or networks. I'm updating</div><div>policy rules in heat so that only project users can manage project resources</div><div>in Heat like stacks or resources.<br></div><div><br></div><div> [1] <a href="https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#direction-change">https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#direction-change</a></div><div><br></div><div>However this change reveals one potential issue with system resources.</div><div><br></div><div>In heat there are some resource types like OS::Nova::Flavor or OS::Keystone::User</div><div>which is allowed for only system users. (I'll call these resources as "system resources" here)</div><div><br></div><div>Because heat uses user credentials to create resources in backend services, if we require</div><div>project scope for stack/resource management then we are no longer able to create these system</div><div>resources as part of stack. (*1)<br></div><div><br></div><div>There are some options I can think of at this moment.</div><div><br></div><div>1. Deprecate and remove all resources which require system scope</div><div>Pros<br></div><div>- This is most easy solution to be implemented</div><div>Cons</div><div>- This one has the biggest user impact<br></div><div><br></div><div><div>2. Use service credential for resource creation</div><div>Pros:<br></div><div>- This might have smallest user impact</div><div>Cons:<br></div><div>- This requires a relatively big change in heat's architecture, which I've not yet evaluated.<br></div><div>- We need to determine the project scope role to be allowed to do system operation.<br></div><div>  <br></div><div>3. Implement additional project-role in each service to allow creation via stack creation.</div><div>Pros:<br></div><div>- This would avoid user impact.</div><div>Cons:<br></div><div>- requires work in multiple components.</div><div>- We need to determine the project scope role to be allowed to do system operation.</div><div><br></div></div><div>I'm not quite sure which one would be the best. If I can ask for some feedback about these options</div><div>(or any other new options) from heat's perspective and rbac's perspective then it would be nice.</div><div><br></div><div>(*1)</div><div>As of now, nova and neutron no longer allow creating system users to create project resources,</div><div>so system users are no longer able to create stacks with project resources like instances or networks</div><div>with default "new" policies.<br></div><div><br></div><div>Thank you,</div><div>Takashi<br></div><div><br></div><div><br></div></div>