Admin users cannot authenticate properly via admin_domain

Bug #1649106 reported by Greg Mason on 2016-12-11
14
This bug affects 3 people
Affects Status Importance Assigned to Milestone
OpenStack keystone charm
Medium
Liam Young
keystone (Juju Charms Collection)
Medium
Liam Young

Bug Description

When deployed as keystone v3, auth via the domain admin_domain isn't fully functional. When trying to run "openstack domain list" or "openstack user list" keystone responds with a 403:

$ openstack user list
You are not authorized to perform the requested action: identity:list_users (HTTP 403) (Request-ID: req-xxxxxxx)

Any admin users in the domain admin_domain should be able to list domains, users, and should be able to create users.

Performing similar operations via Horizon succeed, however this is a poor workaround.

Greg Mason (gmason) on 2016-12-11
summary: - admin user cannot authenticate properly via admin_domain
+ Admin users cannot authenticate properly via admin_domain
Liam Young (gnuoy) wrote :

Are you creating a new admin user and trying to do a domain list? Or are you getting a domain scoped token from the 'admin' user in the admin domain as per https://wiki.ubuntu.com/OpenStack/OpenStackCharms/ReleaseNotes1604#Keystone_v3_API_support ?

Changed in keystone (Juju Charms Collection):
status: New → Incomplete
Liam Young (gnuoy) wrote :

I'm going to grab this bug and update the README off the back of it because this is not the first time people have had issues with authenticating against a v3 cloud.

Changed in keystone (Juju Charms Collection):
assignee: nobody → Liam Young (gnuoy)
Greg Mason (gmason) wrote :

I've tried to authenticate against the API with the following environment variables populated:

OS_REGION_NAME=redacted
OS_USER_DOMAIN_NAME=admin_domain
OS_IDENTITY_API_VERSION=3
OS_PASSWORD=redacted
OS_DOMAIN_NAME=admin_domain
OS_AUTH_URL=http://redacted:35357/v3
OS_USERNAME=admin

I still get a 403 when I try to list users or domains via the openstack cli client.

Joey Stanford (joey) on 2016-12-12
Changed in keystone (Juju Charms Collection):
status: Incomplete → New
tags: added: bootstack-is
tags: added: canonical-bootstack
removed: bootstack-is
Greg Mason (gmason) wrote :

Here is a copy of policy.json from the environment. To me, this looks like it should work for listing users or domains, unless admin_and_matching_domain_id on line 9 is incorrect.

The templates in the charm that are used for policy.json have been edited by hand on the units to add the correct domain id for the cloud_admin rule on line 3. This is the workaround for bug #1637453, which I see is now fixed.

-Greg

Greg Mason (gmason) wrote :

This auth is failing for use with the admin_domain scope. The auth for these operations is failing for the user "admin" and any other users with the role "Admin" in the domain "admin_domain".

Liam Young (gnuoy) wrote :

Greg, when you're setting up the environment variables are you ensuring that no other OS_* variables are set ? fwiw to ensure no other OS_* env vars pollute the environment my novarc looks like this:

_OS_PARAMS=$(env | awk 'BEGIN {FS="="} /^OS_/ {print $1;}' | paste -sd ' ')
for param in $_OS_PARAMS; do
    unset $param
done
unset _OS_PARAMS
export OS_AUTH_URL=${OS_AUTH_PROTOCOL:-http}://`juju-deployer -f keystone`:5000/v3
export OS_USERNAME=admin
export OS_PASSWORD=openstack
export OS_REGION_NAME=RegionOne
export OS_DOMAIN_NAME=admin_domain
export OS_USER_DOMAIN_NAME=admin_domain
export OS_IDENTITY_API_VERSION=3
# Swift needs this:
export OS_AUTH_VERSION=3

Greg Mason (gmason) wrote :

Yes, the novarc I'm using has that function.

When I've tested different combinations of environment variables, I've been sure to use unset to clean up the environment, and checking the output of env to be sure of what the environment has set. The variables I provided earlier were in the output of "env | grep OS_" rather than a novarc.

Liam Young (gnuoy) on 2016-12-14
Changed in keystone (Juju Charms Collection):
status: New → Confirmed
James Page (james-page) on 2016-12-14
Changed in keystone (Juju Charms Collection):
importance: Undecided → Medium
status: Confirmed → In Progress
tags: added: v3
Liam Young (gnuoy) wrote :

The issue was the roles granted to the admin user by the charm. The 'admin' user should be granted the 'Admin' role against the 'admin_domain' but for some reason the 'admin' user only had the 'Member' role against the 'admin_domain'.

Querying the keystone database directly shows how the grants should look:

select a.type, c.name, d.name
from assignment a, local_user b, role c, project d
where a.actor_id = b.user_id
and b.name = 'admin'
and c.id = a.role_id
and d.id = a.target_id;

+-------------+--------+--------------+
| type | name | name |
+-------------+--------+--------------+
| UserProject | Admin | admin |
| UserProject | Member | admin |
| UserDomain | Admin | admin_domain |
+-------------+--------+--------------+

However in the case of the deployment gmason was having issues I think the query would have shown:

+-------------+--------+--------------+
| type | name | name |
+-------------+--------+--------------+
| UserProject | Admin | admin |
| UserProject | Member | admin |
| UserDomain | Member | admin_domain |
+-------------+--------+--------------+

Liam Young (gnuoy) wrote :

@gmason Could you confirm what the keystone charm setting admin-role is set to in your deployment?

Liam Young (gnuoy) wrote :

@gmason the logs from /var/log/juju/* on the keystone units would also be useful.

I have been unable to reproduce this bug so far but will keep trying.

Greg Mason (gmason) wrote :

the juju keystone admin-role is configured to "Admin"

Here's the output of the MySQL query:
+-------------+--------+--------------+
| type | name | name |
+-------------+--------+--------------+
| UserProject | Admin | admin |
| UserProject | Admin | admin_domain |
| UserDomain | Admin | admin_domain |
| UserDomain | Member | admin_domain |
+-------------+--------+--------------+

Greg Mason (gmason) wrote :

Here are sanitized versions of the requested logs from the environment.

James Page (james-page) on 2017-02-23
Changed in charm-keystone:
assignee: nobody → Liam Young (gnuoy)
importance: Undecided → Medium
status: New → In Progress
Changed in keystone (Juju Charms Collection):
status: In Progress → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers