Open Stack

I found that Ussuri implements the old behaviour by default, and the new 
behaviour must be configured with

[oslo_policy]
enforce_scope = true
enforce_new_defaults = true

in each service configuration file (I have not checked whether services 
other than Keystone and Nova observe these new oslo_policy settings).

On 6/1/2020 2:25 PM, Bernd Bausch wrote:
>
> 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 at keystone |grep admin_project_name
> Jun 01 11:49:55 ussuri devstack at 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 at 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
>
> [1] 
> https://docs.openstack.org/keystone/latest/configuration/config-options.html#resource.admin_project_name
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200601/eaa820c8/attachment.html>