<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>I found that Ussuri implements the old behaviour by default, and
the new behaviour must be configured with <br>
</p>
<p><tt>[oslo_policy]<br>
enforce_scope = true</tt><tt><br>
</tt><tt>enforce_new_defaults = true</tt></p>
<p>in each service configuration file (I have not checked whether
services other than Keystone and Nova observe these new
oslo_policy settings).<br>
</p>
<div class="moz-cite-prefix">On 6/1/2020 2:25 PM, Bernd Bausch
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:6c57a5f6-551a-9aa1-66ba-166d5166f14f@gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<p>This is on a stable/ussuri Devstack that I spun up about ten
days ago.<br>
</p>
<p>The documentation for Keystone config option <tt>admin_project_name</tt>
says [1] "If left unset, then there is no admin project". It is
not set in my cloud, as evidenced by this:</p>
<p><tt>$ sudo journalctl -u devstack@keystone |grep
admin_project_name</tt><tt><br>
</tt><tt>Jun 01 11:49:55 ussuri <a
class="moz-txt-link-abbreviated"
href="mailto:devstack@keystone.service"
moz-do-not-send="true">devstack@keystone.service</a>[806]:
DEBUG uwsgi [-] <font color="#0000ff"><b>resource.admin_project_name
= None </b></font>{{(pid=2063) log_opt_values
/usr/local/lib/python3.6/dist-packages/oslo_config/cfg.py:2589}}</tt><br>
</p>
<p>However, when authenticating with any project, I see <tt>'is_admin_project':
True</tt> in the log, for example here user <i>linda </i>with
a project-scoped token for project <i>moon</i>:</p>
<p><tt>Jun 01 13:55:09 ussuri <a class="moz-txt-link-abbreviated"
href="mailto:devstack@keystone.service"
moz-do-not-send="true">devstack@keystone.service</a>[806]:
DEBUG
keystone.server.flask.request_processing.middleware.auth_context
[None req-4d730134-9544-4475-a72f-b2394863345e <font
color="#0000ff"><b>moon linda</b></font>] 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'], <font
color="#0000ff"><b>'is_admin_project': True</b></font>,
'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}}</tt><br>
</p>
<p>It gets worse. When I configure <tt>admin_project_name=admin</tt>
and <tt>admin_project_domain_name=Default</tt>, I do see <tt>is_admin_project:
false</tt> in the log, as expected. Still, <i>linda</i>, who
has the admin role in the <i>moon </i>project,<i> </i>seems
to have cloud admin powers. I tested this by creating a Cinder
volume type and by listing all instances in the cloud.<br>
</p>
<p>So it seems to me that Keystone's old behaviour is in effect: I
have admin powers if I have the <i>admin </i>role in any
project. To me, this looks like a clash between reality and
documentation. Am I missing something?</p>
<p>Thanks for comments.</p>
<p>Bernd<br>
</p>
<p>[1]
<a class="moz-txt-link-freetext"
href="https://docs.openstack.org/keystone/latest/configuration/config-options.html#resource.admin_project_name"
moz-do-not-send="true">https://docs.openstack.org/keystone/latest/configuration/config-options.html#resource.admin_project_name</a><br>
</p>
</blockquote>
</body>
</html>