Open Stack

Hi Rico.

Thank you for your insights.
Please find my replies inline.

On Wed, Mar 9, 2022 at 6:22 PM Rico Lin <ricolin at ricolky.com> wrote:

>
>
> On Wed, Mar 9, 2022 at 1:57 PM Takashi Kajinami <tkajinam at redhat.com>
> wrote:
> >
> > Hello,
> >
> >
> > I've been working on updating policy rules in heat according to the
> latest
> > guideline for SRBAC implementation.
>
> Thanks so much for working on it, definitely +1 on enhancing security.
>
> >
> >  [1]
> https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#direction-change
> >
> > However this change reveals one potential issue with system resources.
> >
> > In heat there are some resource types like OS::Nova::Flavor or
> OS::Keystone::User
> > which is allowed for only system users. (I'll call these resources as
> "system resources" here)
>
> We create those resources based on checking `role:admin`, so project admin
> is accepted.
> This means a user under that project with role:admin, can operate those
> resources.
> I'm not sure what system user means here, so correct me if I'm wrong.
>

The core problem is that backend services like nova enforces different
policies from just role:admin when
SRBAC is enforced. I reported that a while ago as
https://storyboard.openstack.org/#!/story/2009787 .

The main problem here is that heat currently supports resources which
require different scopes of credentials.
For example, once all deprecated policy rules are removed, nova allows
project users to create instances(OS::Nova::Server)[1],
while nova allows only system admins to create
flavors(OS::Nova::Flavor)[2]. Currently Heat leverages the user credential
used to create a stack when Heat requests backend services to create its
resources, and it's "impossible" to create a stack
with these two resources by a single credential (as each token can be
scoped by project or system.

[1]
https://github.com/openstack/nova/blob/d1b036fdb124d1ef48f5cf024d4677bfe5b481d7/nova/policies/servers.py#L210
[2]
https://github.com/openstack/nova/blob/d1b036fdb124d1ef48f5cf024d4677bfe5b481d7/nova/policies/flavor_manage.py#L28-L36

If we keep allowing system users to create stacks, then it would allow
users to create system resources
like flavors. But this never solves the problem with the "mixed" pattern
which I described above.
Hope this will explain these three options more clearly.


>
> >
> > 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
> > Pros
> > - This is most easy solution to be implemented
> > Cons
> > - This one has the biggest user impact
>
> Don't :)
>
> > 2. Use service credential for resource creation
> > Pros:
> > - This might have smallest user impact
> > Cons:
> > - 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
> operation.
> >
>
> I think this is something we can discuss more.
>
> > 3. Implement additional project-role in each service to allow creation
> via stack creation.
> > Pros:
> > - This would avoid user impact.
> > Cons:
> > - requires work in multiple components.
> > - We need to determine the project scope role to be allowed to do system
> operation
>
>
> Indeed current stack operation require `(role:admin and system_scope:all)
> OR (role:member and project_id:%(project_id)s)`.
> 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.
>
The main problem here is that nova will no longer allow project admins to
create flavors,
and it will require system admin when SRBAC is enforced(which means all
deprecated rules
are disabled)


>
> Also, note that
> 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.
>

> So if we go with removing the system admin, that means it's time to also
> remove some deprecated global scope operation.
>
> IMO, to accept Project Admin or member make more reasonable (like you
> proposed in option 3)
>
> >
> > Thank you,
> > Takashi
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220309/1a7a5a95/attachment.htm>