[service_user] config section uses the wrong user_domain_id and project_domain_id
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Cinder Charm |
New
|
Undecided
|
Unassigned |
Bug Description
While testing the service token support I noticed that the following command was returning a different uuid than the one configured in the various services' [service_user] config section:
openstack user show --domain service_domain -f value -c id nova
The reason why is because charm-keystone creates two service users, one for the service_domain, and the other for the Default domain. [1] This is expected as can be seen by the commit that introduced them [2]. That commit introduced 2 service users, one in project config(
What we have now:
[service_user]
send_service_
auth_type = password
auth_url = https:/
project_domain_id = default
user_domain_id = default
project_name = services
username = cinderv3
password = y429YLBM9yLF5fX
What we should have:
[service_user]
send_service_
auth_type = password
auth_url = https:/
project_domain_name = service_domain
user_domain_name = service_domain
project_name = services
username = cinderv3
password = y429YLBM9yLF5fX
[1] charm-keystone creates two services users/projects, one for the service_domain, and the other for the Default domain
root@f1:~# openstack user list --domain service_domain
+------
| ID | Name |
+------
| b14d94f15947431
| 5ce32364e6a043a
| 0ae3b2494e7d491
| ed3ba0b081e641d
| ad43075877b0422
+------
root@f1:~# openstack user list --domain Default
+------
| ID | Name |
+------
| 2a93390dae55464
| 1eabe59fe8f54e2
| 6fd21eba472b445
| b72ef27dd14d409
| 9298849a6c694e0
| 5d4e45bdfa8a4a7
+------
root@f1:~# openstack project list
+------
| ID | Name |
+------
| 2e2dfd384b3c475
| 605138c74dca4d5
| 9f2c31fb6eda427
| b51818605b4d4ef
| c8126e3e9461487
| fdb19396eb66473
+------
root@f1:~# openstack project show 605138c74dca4d5
+------
| Field | Value |
+------
| description | Created by Juju |
| domain_id | 5729b883ec844bc
| enabled | True |
| id | 605138c74dca4d5
| is_domain | False |
| name | services |
| options | {} |
| parent_id | 5729b883ec844bc
| tags | [] |
+------
root@f1:~# openstack domain list
+------
| ID | Name | Enabled | Description |
+------
| 5009f8b773f74d6
| 5729b883ec844bc
| 7c8dbe4036d5479
| default | Default | True | The default domain |
+------
root@f1:~# openstack project show b51818605b4d4ef
+------
| Field | Value |
+------
| description | Created by Juju |
| domain_id | default |
| enabled | True |
| id | b51818605b4d4ef
| is_domain | False |
| name | services |
| options | {} |
| parent_id | default |
| tags | [] |
+------
These are created in charm-keystone/
1641 def _ensure_
1642 ...
1653 if get_api_version() > 2:
1654 ...
1661 create_
1662 ...
1666 ...
1667 create_
[2] Commit that introduced 2 service users, one in project config(
commit 5de1770931e8867
Author: Frode Nordahl <email address hidden>
Date: Wed Nov 2 13:21:07 2016 +0100
Create service credentials in SERVICE_DOMAIN
Cleanup code that references users, projects or domains without
necessary scoping or filtering throughout the charm. Add logging
of domain name in contexts where this is relevant.
Tighten rule:service_role to require role:service and token scoped
to project config(
ensures that if you have a deployment with end-user access to assign
roles within their own domains they will not gain privileged access
simply by assigning the service role to one of their own users.
Allow users authorized by rule:service_role to perform
identity:
to operate without Admin privileges.
Services are given a user in project config(
SERVICE_DOMAIN for v3 authentication / authorization. As of Mitaka
Keystone v3 policy the 'service' role is sufficient for services to
validate tokens.
Services are also given a user in project config(
DEFAULT_DOMAIN to support services still configured with v2.0
authentication / authorization.
This will allow us to transition from v2.0 based authentication /
authorization and existing services and charms will continue to
operate as before. This will also allow the end-user to roll their
deployment up to api_version 3 and back to api_version 2 as needed.
Services and charms that has made the transition to fully use the
v3 API for authentication and authorization will gain full access to
domains and projects across the deployment. The first charm to make
use of this is charm-ceilometer.
Closes-Bug: 1636098
Change-Id: If1518029c43476
https:/ /github. com/juju/ charm-helpers/ pull/813 is a fix to it.