<div dir="ltr"><div dir="ltr"><div>Hi Rico.</div><div><br></div><div>Thank you for your insights.</div><div>Please find my replies inline.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 9, 2022 at 6:22 PM Rico Lin <<a href="mailto:ricolin@ricolky.com">ricolin@ricolky.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><br>On Wed, Mar 9, 2022 at 1:57 PM Takashi Kajinami <<a href="mailto:tkajinam@redhat.com" target="_blank">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" target="_blank">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></div></blockquote><div><br></div><div>The core problem is that backend services like nova enforces different policies from just role:admin when</div><div>SRBAC is enforced. I reported that a while ago as <a href="https://storyboard.openstack.org/#!/story/2009787">https://storyboard.openstack.org/#!/story/2009787</a> .<br></div><div><br></div><div>The main problem here is that heat currently supports resources which require different scopes of credentials.</div><div>For example, once all deprecated policy rules are removed, nova allows project users to create instances(OS::Nova::Server)[1],</div><div>while nova allows only system admins to create flavors(OS::Nova::Flavor)[2]. Currently Heat leverages the user credential</div><div>used to create a stack when Heat requests backend services to create its resources, and it's "impossible" to create a stack</div><div>with these two resources by a single credential (as each token can be scoped by project or system.</div><div><br></div><div>[1] <a href="https://github.com/openstack/nova/blob/d1b036fdb124d1ef48f5cf024d4677bfe5b481d7/nova/policies/servers.py#L210">https://github.com/openstack/nova/blob/d1b036fdb124d1ef48f5cf024d4677bfe5b481d7/nova/policies/servers.py#L210</a></div><div>[2] <a href="https://github.com/openstack/nova/blob/d1b036fdb124d1ef48f5cf024d4677bfe5b481d7/nova/policies/flavor_manage.py#L28-L36">https://github.com/openstack/nova/blob/d1b036fdb124d1ef48f5cf024d4677bfe5b481d7/nova/policies/flavor_manage.py#L28-L36</a></div><div><br></div><div>If we keep allowing system users to create stacks, then it would allow users to create system resources</div><div>like flavors. But this never solves the problem with the "mixed" pattern which I described above.</div><div>Hope this will explain these three options more clearly.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><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></div></div></blockquote><div>The main problem here is that nova will no longer allow project admins to create flavors,</div><div>and it will require system admin when SRBAC is enforced(which means all deprecated rules</div><div>are disabled)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><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></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><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>
</blockquote></div></div>