Open Stack

On 03/09/2018 01:42 AM, Adrian Turjak 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/
Thanks for the traces, I've opened a bug [0]. We should find a way to
handle the ambiguity.

[0] https://bugs.launchpad.net/keystone/+bug/1754677
>
> 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.
>
> 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.
>
> 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...
>
>
> 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?
There used to be a more distinct different between projects and domains
before we decided to chase reseller use cases [1]. Projects and domains
were two distinct things prior to that. Domains ended up becoming the
root of the tree and they were munged with projects. The goal of
reseller was to try and make it easier for a customer to setup domains
under the domain they got from the provider. With that came a slew of
security problems that resulted in punting the ability to have a domain
anywhere but the root of the tree. The reseller case hasn't been picked
up since.

[1]
http://specs.openstack.org/openstack/keystone-specs/specs/keystone/mitaka/reseller.html
>
> 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.
>
> 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
>
>
>
> __________________________________________________________________________
> 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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180309/2a12a7b1/attachment.sig>