On Fri, Mar 9, 2018 at 2:42 AM, Adrian Turjak <adri...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev