<div dir="ltr"><br><br>On Wed, Mar 9, 2022 at 1:57 PM Takashi Kajinami <<a href="mailto:tkajinam@redhat.com">tkajinam@redhat.com</a>> wrote:<br>><br>> Hello,<br>><br>><br>> I've been working on updating policy rules in heat according to the latest<br>> guideline for SRBAC implementation.<br><br><div>Thanks so much for working on it, definitely +1 on enhancing security.<div><br>><br>>  [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><br>><br>> However this change reveals one potential issue with system resources.<br>><br>> In heat there are some resource types like OS::Nova::Flavor or OS::Keystone::User<br>> which is allowed for only system users. (I'll call these resources as "system resources" here)</div><div><br></div><div>We create those resources based on checking `role:admin`, so project admin is accepted.</div><div>This means a user under that project with role:admin, can operate those resources.</div><div>I'm not sure what system user means here, so correct me if I'm wrong.</div><div><br>><br>> Because heat uses user credentials to create resources in backend services, if we require<br>> project scope for stack/resource management then we are no longer able to create these system<br>> resources as part of stack. (*1)</div><div>><br>> There are some options I can think of at this moment.<br>><br>> 1. Deprecate and remove all resources which require system scope<br>> Pros<br>> - This is most easy solution to be implemented<br>> Cons<br>> - This one has the biggest user impact<br><br></div><div>Don't :)</div><div><br>> 2. Use service credential for resource creation<br>> Pros:<br>> - This might have smallest user impact<br>> Cons:<br>> - This requires a relatively big change in heat's architecture, which I've not yet evaluated.<br>> - We need to determine the project scope role to be allowed to do system operation.<br>>  </div><div><br></div><div>I think this is something we can discuss more.</div><div><br>> 3. Implement additional project-role in each service to allow creation via stack creation.<br>> Pros:<br>> - This would avoid user impact.<br>> Cons:<br>> - requires work in multiple components.<br>> - We need to determine the project scope role to be allowed to do system operation<br></div><div><br></div><div><div><br></div><div>Indeed current stack operation require `(role:admin and system_scope:all) OR (role:member and project_id:%(project_id)s)`.</div><div>And if we remove the system part and keep `(role:member and project_id:%(project_id)s)`, will mean only a user in that project with a member role can operate stack, and if the user got also admin role, that user can manage User/Flavor resources through stack too.</div><div><br></div><div>Also, note that</div><div>For the case of Nova::Flavor, both policies from Nova and Heat resource will be enforced here, so it only accepts the intersection part of rules.</div><div><br></div><div>So if we go with removing the system admin, that means it's time to also remove some deprecated global scope operation.</div><div><br></div><div>IMO, to accept Project Admin or member make more reasonable (like you proposed in option 3)</div><div></div><br>><br>> Thank you,<br>> Takashi<br>><br></div></div></div>