[openstack-dev] [Keystone] Weirdness around domain/project scope in role assignments
ayoung at redhat.com
Fri Mar 9 15:37:13 UTC 2018
On Fri, Mar 9, 2018 at 2:42 AM, Adrian Turjak <adriant at catalyst.net.nz>
> 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:
> The amusing part, I now can't remove the above role assignments. They
> throw a 500:
> The error itself being:
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:
> 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:
> 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?):
> 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:
> 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:
> "identity:list_projects": "rule:cloud_admin or
> - "cloud_admin": "role:admin and (is_admin_project:True or
> - "admin_and_matching_domain_id": "rule:admin_required and
> - "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):
> 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
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev