[horizon] Yoga: Syntax of new Parameter SYSTEM_SCOPE_SERVICES in local_settings.py
Hi there, We have started to analyze Openstack Yoga a bit and there, one of the major new feature is the activation of scope based token for regular use in nova. While after some long lasting back and forth in configuring our role assignments and policies we could make it work on one of our test environments (Ubuntu) via Openstack SDK, however, we are still struggling with some system scoped API calls to nova from horizon. We have an admin user for the domain 'Default' who has set the role ‚admin' for 'system all': +-------+---------------+-------+---------+--------+--------+-----------+ | Role | User | Group | Project | Domain | System | Inherited | +-------+---------------+-------+---------+--------+--------+-----------+ | admin | admin@Default | | | | all | False | +-------+---------------+-------+---------+--------+--------+-----------+ We have configured in local_settings.py: SYSTEM_SCOPE_SERVICES = ['compute', 'image', 'volume', 'network‘] (Note: this config line has been reverse engineered from horizon source code as the syntax is nowhere possible to be found in the docs yet … - so: not sure if it is correct) Policy files are identical for horizon as for the services. For the user admin, we then get an additional field in the domain/project top line menu adding a ‚system scope‘ switch (this is what we understand how it should look like) and - when switching to system scope - also a system menu in the sidebar (also as expected). If we then go to System->Systeminformation to see the nova service list, we get an error ‚Unable to get nova services list‘, given reason is an error: 'Policy doesn’t allow os_compute_api:os-services:list to be performed (HTTP 403)‘. Informations for network and volume services are shown normally (here scoped tokens are not activated yet). Further analysis indicated that horizon is using still a project-scoped token and not a system-scoped one for these requests although ’system scope’ is active. Putting the same request from Openstack SDK with the same user admin results in $ openstack compute service list /usr/lib/python3/dist-packages/secretstorage/dhcrypto.py:15: CryptographyDeprecationWarning: int_from_bytes is deprecated, use int.from_bytes instead from cryptography.utils import int_from_bytes /usr/lib/python3/dist-packages/secretstorage/util.py:19: CryptographyDeprecationWarning: int_from_bytes is deprecated, use int.from_bytes instead from cryptography.utils import int_from_bytes +----+------------------+-------------+----------+---------+-------+----------------------------+ | ID | Binary | Host | Zone | Status | State | Updated At | +----+------------------+-------------+----------+---------+-------+----------------------------+ | 4 | nova-consoleauth | controller | nova | enabled | down | 2019-10-31T14:59:33.000000 | | 5 | nova-scheduler | controller | nova | enabled | up | 2022-05-04T08:52:48.000000 | | 6 | nova-conductor | controller | nova | enabled | up | 2022-05-04T08:52:42.000000 | | 12 | nova-compute | compute3 | Crandale | enabled | up | 2022-05-04T08:52:40.000000 | | 13 | nova-conductor | controller3 | nova | enabled | down | 2020-06-28T14:45:31.000000 | | 14 | nova-scheduler | controller3 | nova | enabled | down | 2020-06-28T14:45:24.000000 | +----+------------------+-------------+----------+---------+-------+—————————————--------------—+ Which indicates that role assignments to user admin are correct. The same command with -—debug also proves that a system scoped token is generated. Before I consider to open a bug towards Horizon: Could someone indicate to me whether the syntax of the config needs some adaptions to make it work or confirm that it is correct? Is there any other aspect we overlooked? I am looking forward to your reply Best regards Clemens
Hi Crandale, On Wed, May 4, 2022 at 6:00 PM Crandale <clemens.hardewig@crandale.de> wrote:
Hi there,
We have started to analyze Openstack Yoga a bit and there, one of the major new feature is the activation of scope based token for regular use in nova. While after some long lasting back and forth in configuring our role assignments and policies we could make it work on one of our test environments (Ubuntu) via Openstack SDK, however, we are still struggling with some system scoped API calls to nova from horizon.
We have an admin user for the domain 'Default' who has set the role ‚admin' for 'system all': +-------+---------------+-------+---------+--------+--------+-----------+ | Role | User | Group | Project | Domain | System | Inherited | +-------+---------------+-------+---------+--------+--------+-----------+ | admin | admin@Default | | | | all | False | +-------+---------------+-------+---------+--------+--------+-----------+
We have configured in local_settings.py:
SYSTEM_SCOPE_SERVICES = ['compute', 'image', 'volume', 'network‘]
(Note: this config line has been reverse engineered from horizon source code as the syntax is nowhere possible to be found in the docs yet … - so: not sure if it is correct)
Yes, the above syntax is correct to enable System Scope for different OpenStack services in the horizon. You can refer to horizon documentation for more info. [1]. I will push a patch to add more information about this in horizon docs. [1] https://docs.openstack.org/horizon/latest/configuration/settings.html#system... Policy files are identical for horizon as for the services.
For the user admin, we then get an additional field in the domain/project top line menu adding a ‚system scope‘ switch (this is what we understand how it should look like) and - when switching to system scope - also a system menu in the sidebar (also as expected).
If we then go to System->Systeminformation to see the nova service list, we get an error ‚Unable to get nova services list‘, given reason is an error: 'Policy doesn’t allow os_compute_api:os-services:list to be performed (HTTP 403)‘. Informations for network and volume services are shown normally (here scoped tokens are not activated yet).
Further analysis indicated that horizon is using still a project-scoped token and not a system-scoped one for these requests although ’system scope’ is active.
It is a known issue in the horizon, that's why we disable System Scope Support by default. As of now, only keystone and a few neutron panels work if you enable System Scope Support in the horizon. Horizon team plans to fix this issue once it is fixed on the nova side. Putting the same request from Openstack SDK with the same user admin
results in
$ openstack compute service list /usr/lib/python3/dist-packages/secretstorage/dhcrypto.py:15: CryptographyDeprecationWarning: int_from_bytes is deprecated, use int.from_bytes instead from cryptography.utils import int_from_bytes /usr/lib/python3/dist-packages/secretstorage/util.py:19: CryptographyDeprecationWarning: int_from_bytes is deprecated, use int.from_bytes instead from cryptography.utils import int_from_bytes
+----+------------------+-------------+----------+---------+-------+----------------------------+ | ID | Binary | Host | Zone | Status | State | Updated At |
+----+------------------+-------------+----------+---------+-------+----------------------------+ | 4 | nova-consoleauth | controller | nova | enabled | down | 2019-10-31T14:59:33.000000 | | 5 | nova-scheduler | controller | nova | enabled | up | 2022-05-04T08:52:48.000000 | | 6 | nova-conductor | controller | nova | enabled | up | 2022-05-04T08:52:42.000000 | | 12 | nova-compute | compute3 | Crandale | enabled | up | 2022-05-04T08:52:40.000000 | | 13 | nova-conductor | controller3 | nova | enabled | down | 2020-06-28T14:45:31.000000 | | 14 | nova-scheduler | controller3 | nova | enabled | down | 2020-06-28T14:45:24.000000 |
+----+------------------+-------------+----------+---------+-------+—————————————--------------—+
Which indicates that role assignments to user admin are correct. The same command with -—debug also proves that a system scoped token is generated.
Before I consider to open a bug towards Horizon: Could someone indicate to me whether the syntax of the config needs some adaptions to make it work or confirm that it is correct?
Is there any other aspect we overlooked?
I am looking forward to your reply
Best regards
Clemens
Thanks & regards, Vishal Manchanda
participants (2)
-
Crandale
-
vishal manchanda