[rdo-list] Understanding Policy.Json, for domain authorization

Wed Nov 2 08:35:03 UTC 2016

I've found parts of the problem, but here is my policy.json excerpt:

    "cloud_admin": "role:admin and (token.is_admin_project:True or
domain_id:d8aaf957fa5d4ced85cf308d464e0020)",
    "admin_and_matching_domain_id": "rule:admin_required and
domain_id:%(domain_id)s",
    "identity:get_domain": "rule:cloud_admin or
rule:admin_and_matching_domain_id or token.project.domain.id:%(
target.domain.id)s",
    "identity:list_projects": "rule:cloud_admin or
rule:admin_and_matching_domain_id",
    "identity:list_user_projects": "rule:owner or
rule:admin_and_matching_domain_id",
    "identity:list_users": "rule:cloud_admin or
rule:admin_and_matching_domain_id",
    "identity:list_groups": "rule:cloud_admin or
rule:admin_and_matching_domain_id",
    "identity:list_users_in_group": "rule:cloud_admin or
rule:admin_and_matching_target_group_domain_id",

The cause of problem was the keystonerc-file I was sourcing, but I cant
help wondering wether this error should be possible to avoid, and it seems
I am still not all the way home...This was my inital keystonerc_admin:

export OS_PROJECT_DOMAIN_NAME=Default
export OS_USER_DOMAIN_NAME=Default
export OS_PROJECT_NAME=admin
export OS_USERNAME=admin
export OS_PASSWORD=admin00
export OS_AUTH_URL=http://172.16.12.100:35357/v3
export OS_IDENTITY_API_VERSION=3
export OS_IMAGE_API_VERSION=2

I realized from ngrepping on the keystone api at :35357, that openstack was
asking for a project scoped token, (which I thought I needed since my
belief was that a domain-local admin should only have admin-role on a
project in the domain but that doesnt seem to be the case?), but reading
the policy rule made me realise that the "admin_required and domain_id:"
wanted a domain-scoped token.

So I ran "openstack user list  --os-domain-name default", trying to get a
domain scoped token, with the admin role, since my default admin user in
the default domain, has the admin role on both default domain, and the
admin project in the default domain. (Which seems to be a requirement, even
for a local-domain admin)

However, because of (I assume) the OS_PROJECT_NAME env, the token is
created with a:

{"auth": {"scope": {"project": {"domain": {"name": "Default"}, "name":
"admin"}}, "identity": {"password": {"user": {"domain": {"name":
"Default"}, "password": "admin00", "name": "admin"}}, "methods":
["password"]}}}

Now, yes, defining *both* OS_PROJECT_NAME and using --os-domain-name default
is of course kinda stupid, but since I can only have EITHER project scoped
OR domain scoped tokens, isnt it kind of a bug that the openstack CLI is
trying to give me a project scoped token, using the DOMAIN NAME???

However, it still doesnt work 100% correctly I think. Undefining OS_PROJECT
NAME, and running

"openstack user list --os-domain-name Default"

*Will still not work*. I have to do:

"openstack user list --os-domain-name Default --domain *default* "

And the reason I dont like that, is that I have to know the domain
*UUID*(default),
which a normal project/domain-*local* admin cant find out, because of the
rule for identity:get_domain which said:

    "identity:get_domain": "rule:cloud_admin or
rule:admin_and_matching_domain_id or token.project.domain.id:%(
target.domain.id)s",

The only way I can do openstack domain show <domain>, is if I already now
the uuid to begin with...

Running

openstack user list --os-domain-name Default --domain Default
openstack domain show --os-domain-name Default Default

result in: "Could not find resource Default"

So. Maybe I can fix this by allowing domain-names in the rule for
get_domain, but since I cant fathom that I would be the first to try to
list users with a domain local admin-user, I cant believe that I need to
change the recently downloaded policy file.

Surely the major users of Openstack have started using domains by now?

Best Regards
Taisto Qvist

2016-11-01 22:17 GMT+01:00 Taisto Qvist <taisto.qvist at gmail.com>:

> Hi folks,
>
> I've run into a wall with making openstack domain auth working, and I dont
> know where to get help, so I am trying here. I've created a question on:
>
> https://ask.openstack.org/en/question/98429/project-
> specific-admin-unable-to-list-users-or-use-horizon/
>
> ..but no-one seems to be able to help.
>
> Since I wrote that, I've gotten as far as creating a working cloud-wide
> admin(the policy trigger for cloud_admin matching against domain_id, didnt
> seem to work for the default domain...?), and that user is now working fine
> as super-mega-admin.
>
> But my old admin user, that has admin rights only in the default domain,
> admin project, cant list users, or projects, in the default domain.
>
> And sureley he should be able to, with the rules:
>
>     "admin_and_matching_domain_id": "rule:admin_required and
> domain_id:%(domain_id)s",
>     "identity:list_users": "rule:cloud_admin or rule:admin_and_matching_domain_id",
>
>
> I've tried to find comprehensive and up2date references on how to read the
> policy.json syntax, but no success so I am unsure on how to interpret the
> rule exactly though.
> I tried changing to:
>
>     "admin_and_matching_domain_id": "rule:admin_required and domain_id:%(
> *target*.domain_id)s",
>
> after looking at the rule for:
>
>     "identity:get_project": "rule:cloud_admin or rule:admin_and_matching_target_project_domain_id
> or project_id:%(target.project.id)s",
>
> But it didnt help. During the failure, I can see keystone logging:
>
> 2016-11-01 22:16:24.521 4824 INFO keystone.common.wsgi
> [req-46e3301f-f234-434b-a013-5aa2297b6119 admin_User
> admin_Prj                        - default default] GET
> http://172.16.12.100:35357/v3/projects/admin_Prj
>
> (where admin_Prj/User is the UUID's regexped)
>
> What is wrong? Where can I learn how to do this???
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rdoproject.org/pipermail/dev/attachments/20161102/42e79051/attachment.html>