Open Stack

On Fri, Mar 9, 2018 at 2:42 AM, Adrian Turjak <adriant at catalyst.net.nz>
wrote:

> Sooo to follow up from the discussion last night partly with Lance and
> Adam, I'm still not exactly sure what difference, if any, there is
> between a domain scoped role assignment, and a project scoped role
> assignment. And... It appears stuff breaks when you used both, or either
> actually (more on that further down).
>
> My problem/confusion was why the following exists or is possible:
> http://paste.openstack.org/show/695978/
> The amusing part, I now can't remove the above role assignments. They
> throw a 500:
> http://paste.openstack.org/show/696013/
> The error itself being:
> http://paste.openstack.org/show/695994/





This is a bug.  It looks like the one() assumes there is only every one
record that comes back that matches, and this matches multiple.

A 500 is never appropriate.


>
>
> Then lets look at just project scope:
> http://paste.openstack.org/show/696007/
> I can't seem to do 'include_names' on the project scoped role
> assignment, but effective works since it doesn't include the project. I
> have a feeling the error is because keystone isn't including projects
> with is_domain when doing the names mapping.
>

Probably correct. Bug on this, too.




>
> So... going a little further, does domain scope still act like project
> scope in regards to effective roles:
> http://paste.openstack.org/show/695992/
> The answer is yes. But again, this is domain scope, not project scope
> which still results in project scope down the tree. Although here
> 'include_names' works, this time because keystone internally is directly
> checking for is_domain I assume.
>

Interesting.  That might have been a "works as designed"  with the idea
that assigning a role on a domain that is inherited is used by anything
underneath it.  It actually makes sense, as domains can't nest, so this
may be intentional syntactic sugar on top of the format I used:




>
> Also worth mentioning that the following works (and maybe shouldn't?):
> http://paste.openstack.org/show/696006/
> Alice has a role on a 'project' that isn't part of her domain. I can't
> add her to a project that isn't in her domain... but I can add her to
> another domain? That surely isn't expected behavior...
>
> That is a typo.  You added an additional character at the end of the ID:

86a8b3dc1b8844fd8c2af8dd50cc21386

86a8b3dc1b8844fd8c2af8dd50cc2138





>
> Weird broken stuff aside, I'm still not seeing a difference between
> domain/project role assignment scope on a project that is a domain. Is
> there a difference that I'm missing, and where is such a difference used?
>
> Looking at the blog post Adam linked
> (https://adam.younglogic.com/2018/02/openstack-hmt-cloudforms/), he
> isn't  really making use of domain scope, just project scope on a
> domain, and inheritance down the tree, which is indeed a valid and
> useful case, but again, not domain scope assignment. Although domain
> scope on the same project would probably (as we see above) achieve the
> same result.
>
> Then looking at the policy he linked:
> http://git.openstack.org/cgit/openstack/keystone/tree/etc/
> policy.v3cloudsample.json#n52
> "identity:list_projects": "rule:cloud_admin or
> rule:admin_and_matching_domain_id",
>     - "cloud_admin": "role:admin and (is_admin_project:True or
> domain_id:admin_domain_id)",
>     - "admin_and_matching_domain_id": "rule:admin_required and
> domain_id:%(domain_id)s",
>         -  "admin_required": "role:admin",
>
> I can't exactly see how it also uses domain scope. It still seems to be
> project scope focused.
>
> It is subtle.  domain_id:admin_domain_id  Means that the token has a
domain_id, which means it is a domain scoped token.






> So my question then is why on the role assignment object do we
> distinguish between a domain/project when it comes to scope when a
> domain IS a project, and clearly things break when you set both.
>
> Can we make it so the following works (a hypothetical example):
> http://paste.openstack.org/show/696010/
> At which point the whole idea of 'domain' scope on a role assignment
> goes away since and is exactly the same thing as project scope, and also
> the potential database 500 issues goes away since... there isn't more
> than 1 row. We can then start phasing out the domain scope stuff and
> hiding it away unless someone is explicitly still looking for it.
>
> Because in reality, right now I think we only have project scope, and
> system scope. Domain scope == project scope and we should probably make
> that clear because obviously the code base is confused on that matter. :P
>


I'd love it if Domains went away and we only had projects.  We'd have to
find a way to implement such that people using domains today don't get
broken.
We could also add a 3 value toggle on the inheritance: none, children_only,
both to get it down to a single entry.that would be an implementation
detail that the end users would not see.


The one potential benefit to domain ,which is not used today, is to say:
this applies to all of the projects inside this domain.  Each project knows
both its parent and its domain, so it is a way to jump levels of the tree.





>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180309/fe932b0a/attachment.html>