This is on a stable/ussuri Devstack that I spun up about ten days
ago.
The documentation for Keystone config option admin_project_name says [1] "If left unset, then there is no admin project". It is not set in my cloud, as evidenced by this:
$ sudo journalctl -u devstack@keystone |grep
admin_project_name
Jun 01 11:49:55 ussuri devstack@keystone.service[806]:
DEBUG uwsgi [-] resource.admin_project_name
= None {{(pid=2063) log_opt_values
/usr/local/lib/python3.6/dist-packages/oslo_config/cfg.py:2589}}
However, when authenticating with any project, I see 'is_admin_project': True in the log, for example here user linda with a project-scoped token for project moon:
Jun 01 13:55:09 ussuri devstack@keystone.service[806]: DEBUG
keystone.server.flask.request_processing.middleware.auth_context
[None req-4d730134-9544-4475-a72f-b2394863345e moon linda] RBAC: auth_context:
{'token': <TokenModel (audit_id=1Ie2AyIdRb2WUkaSjSzDoQ,
audit_chain_id=['1Ie2AyIdRb2WUkaSjSzDoQ']) at
0x7fca69b75c88>, 'domain_id': None, 'trust_id': None,
'trustor_id': None, 'trustee_id': None, 'domain_name': None,
'group_ids': [], 'user_id': 'a8c3559f67094f38a5f0d2d0b581f159',
'user_domain_id': 'default', 'system_scope': None, 'project_id':
'163b41b499aa4ac78f2ed968e7fe2a0d', 'project_domain_id':
'default', 'roles': ['admin', 'reader', 'member'], 'is_admin_project': True,
'service_user_id': None, 'service_user_domain_id': None,
'service_project_id': None, 'service_project_domain_id': None,
'service_roles': []} {{(pid=2062) fill_context
/opt/stack/keystone/keystone/server/flask/request_processing/middleware/auth_context.py:478}}
It gets worse. When I configure admin_project_name=admin
and admin_project_domain_name=Default, I do see is_admin_project:
false in the log, as expected. Still, linda, who
has the admin role in the moon project, seems to
have cloud admin powers. I tested this by creating a Cinder volume
type and by listing all instances in the cloud.
So it seems to me that Keystone's old behaviour is in effect: I have admin powers if I have the admin role in any project. To me, this looks like a clash between reality and documentation. Am I missing something?
Thanks for comments.
Bernd