yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #54047
[Bug 1604479] [NEW] tenantId/default_project_id missing on Keystone service user in Mitaka
Public bug reported:
On upgrading to Mitaka, we saw that the user ref in Keystone does not have a tenantId or default_project_id field. This breaks:
1) The Detailed view in Horizon in the Identity pane where ProjectID is shown as "None"
2) any services project based RBAC policies that we have in place.
Noticed a new local_user DB table for all the services users (no project/tenantId field in here):
keystone=# select * from local_user;
id | user_id | domain_id | name
----+----------------------------------+-----------+------------
1 | 3c1bd8c0f6324dcc938900d8eb801aa5 | default | admin
2 | d1c4f7a244f74892b612b9b2ded6d602 | default | neutron
3 | a481a1f43ec0463083b7a30d20493d38 | default | nova
4 | 951068b3372f47ac827ade8f67cc19b4 | default | glance
6 | 4b76763e375946998445b65b11c8db73 | default | ceilometer
7 | 15c8e1e463cc4370ad369eaf8504b727 | default | cinder
8 | 5c3ea23eb8e14070bc562951bb266073 | default | sysinv
9 | 2b62ced877244e74ba90b546225740d0 | default | heat
10 | 5a506282b45c4064b262f3f414f1f699 | default | kam
(9 rows)
Note that an admin role is assigned for these services users in the services project. It is just not present within the user reference or keystone user-get:
$ keystone user-role-list
+----------------------------------+-------+----------------------------------+----------------------------------+
| id | name | user_id | tenant_id |
+----------------------------------+-------+----------------------------------+----------------------------------+
| f9985117736b4684904b4eb55476f30a | admin | a481a1f43ec0463083b7a30d20493d38 | c211dda10c9a4b2db16f239dccf65acd |
+----------------------------------+-------+----------------------------------+----------------------------------+
$ keystone user-get
+----------+----------------------------------+
| Property | Value |
+----------+----------------------------------+
| email | nova@localhost |
| enabled | True |
| id | a481a1f43ec0463083b7a30d20493d38 |
| name | nova |
| username | nova |
+----------+----------------------------------+
Contrast this to Kilo/Liberty where tenantId is visible within user reference:
$ keystone user-get b7a3bcd588b5482ab9741efcf3f9bb33
+----------+----------------------------------+
| Property | Value |
+----------+----------------------------------+
| email | nova@localhost |
| enabled | True |
| id | b7a3bcd588b5482ab9741efcf3f9bb33 |
| name | nova |
| tenantId | 2e4a21e1a37840879321320107c74f86 | <<<<<<<<<<<<<<<<<<<<<<<<<<
| username | nova |
+----------+----------------------------------+
** Affects: keystone
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1604479
Title:
tenantId/default_project_id missing on Keystone service user in Mitaka
Status in OpenStack Identity (keystone):
New
Bug description:
On upgrading to Mitaka, we saw that the user ref in Keystone does not have a tenantId or default_project_id field. This breaks:
1) The Detailed view in Horizon in the Identity pane where ProjectID is shown as "None"
2) any services project based RBAC policies that we have in place.
Noticed a new local_user DB table for all the services users (no project/tenantId field in here):
keystone=# select * from local_user;
id | user_id | domain_id | name
----+----------------------------------+-----------+------------
1 | 3c1bd8c0f6324dcc938900d8eb801aa5 | default | admin
2 | d1c4f7a244f74892b612b9b2ded6d602 | default | neutron
3 | a481a1f43ec0463083b7a30d20493d38 | default | nova
4 | 951068b3372f47ac827ade8f67cc19b4 | default | glance
6 | 4b76763e375946998445b65b11c8db73 | default | ceilometer
7 | 15c8e1e463cc4370ad369eaf8504b727 | default | cinder
8 | 5c3ea23eb8e14070bc562951bb266073 | default | sysinv
9 | 2b62ced877244e74ba90b546225740d0 | default | heat
10 | 5a506282b45c4064b262f3f414f1f699 | default | kam
(9 rows)
Note that an admin role is assigned for these services users in the services project. It is just not present within the user reference or keystone user-get:
$ keystone user-role-list
+----------------------------------+-------+----------------------------------+----------------------------------+
| id | name | user_id | tenant_id |
+----------------------------------+-------+----------------------------------+----------------------------------+
| f9985117736b4684904b4eb55476f30a | admin | a481a1f43ec0463083b7a30d20493d38 | c211dda10c9a4b2db16f239dccf65acd |
+----------------------------------+-------+----------------------------------+----------------------------------+
$ keystone user-get
+----------+----------------------------------+
| Property | Value |
+----------+----------------------------------+
| email | nova@localhost |
| enabled | True |
| id | a481a1f43ec0463083b7a30d20493d38 |
| name | nova |
| username | nova |
+----------+----------------------------------+
Contrast this to Kilo/Liberty where tenantId is visible within user reference:
$ keystone user-get b7a3bcd588b5482ab9741efcf3f9bb33
+----------+----------------------------------+
| Property | Value |
+----------+----------------------------------+
| email | nova@localhost |
| enabled | True |
| id | b7a3bcd588b5482ab9741efcf3f9bb33 |
| name | nova |
| tenantId | 2e4a21e1a37840879321320107c74f86 | <<<<<<<<<<<<<<<<<<<<<<<<<<
| username | nova |
+----------+----------------------------------+
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1604479/+subscriptions
Follow ups
