0

I've been trying to update our OpenStack installation to use new options enforce_new_defaults and enforce_scope since in Wallaby for nova old policies will be deprecated. Those option seem to be present in many components (nova, cinder, keystone, glance, …) so I thought it is good idea to enable them everywhere. I've started with nova and cinder and hit interesting problem.

I've created user test without default project and assigned it admin permissions in system scope and in one project. Both options mentioned before are set to true in nova and cinder. Policy files are absent (because I want to test defaults).

Doing basic test (https://docs.openstack.org/keystone/latest//admin/tokens-overview.html#authorization-scopes):

  • openstack token issue gives me unscoped token
  • openstack --os-system-scope=all token issue gives me system-scoped token
  • openstack --project-name=NAX.Prod token issue gives me project-scoped token

So far so good. Now fun starts:

  • openstack volume service list - FAIL: The service catalog is empty.
  • openstack --os-system-scope=all volume service list - FAIL: public endpoint for volumev3 service not found
  • openstack --os-project-name=NAX.Prod volume service list - OK

System-scoped request does not pass, because volumev3 service uses /v3/%(project_id)s in the endpoint URL (double checked docs) so it seems without authenticating to some project it won't work.

Looking in the generated policy, it seems to not support scopes for this request:

# List all services.
# GET  /os-services
#"volume_extension:services:index": "rule:admin_api"

Fine, now the nova:

  • openstack compute service list - FAIL: The service catalog is empty.
  • openstack --os-system-scope=all compute service list - OK
  • openstack --os-project-name=NAX.Prod compute service list - FAIL: Policy doesn't allow os_compute_api:os-services:list to be performed.

The relevant policy:

# List all running Compute services in a region.
# GET  /os-services
# Intended scope(s): system
#"os_compute_api:os-services:list": "rule:system_reader_api"

So it does seem to work as expected.


That said, if you want to manage OpenStack to perform same operation for different components (list services) you have to use different scopes (different OS_CLOUD or CLI arguments, depending how you have set it up). Is this really expected? Do I miss anything?

Relevant versions:

  • Keystone: 18.0.0
  • Nova: 22.0.1
  • Cinder: 17.0.0
  • OpenStack Client: 5.4.0
  • OpenStack SDK: 0.50.0
  • The scope of the token generated by `openstack token issue` and all other commands depends both on the command line arguments like `--os-system-scope` and the equivalent environment variables like `OS_SYSTEM_SCOPE`. Therefore, I can't be certain what precisely happens during your tests. – berndbausch Feb 07 '21 at 03:40
  • The "volume3 endpoint not found" message makes me wonder if your Cinder is set up correctly. What do you get from `openstack endpoint list`? – berndbausch Feb 07 '21 at 03:41
  • Regarding your question at the end, different OpenStack components could have different authorization rules for similar actions like listing all services. Such inconsistencies, if they exist, would not surprise me, but while they are certainly not ideal, you would have to live with them. – berndbausch Feb 07 '21 at 03:44
  • @berndbausch I omitted setting up OS_AUTH_URL, OS_USER_DOMAIN_NAME, OS_USER and OS_PASSWORD. Other than that, all commands have all options here. Cinder is actually set up as described in the documentation: * `http://controller:8776/v3/%(project_id)s` for `internal` endpoint * `https://controller:8776/v3/%(project_id)s` for `public` and `admin` endpoints Which kinda makes sense that you can't get to cinder API without authorizing to the project but it does not make sense to me how one would use system scope on cinder then. – Igor Raits Feb 07 '21 at 08:51
  • I forgot something important. The system scope is a relatively new concept in Keystone (Stein?), and Nova started supporting in Train or Ussuri. It's likely that Cinder doesn't support it yet. – berndbausch Feb 07 '21 at 11:59
  • Not sure what to do with the endpoint error. – berndbausch Feb 07 '21 at 12:00
  • @berndbausch yeah, I was surprised that Wallaby will have enforce_scope enabled while cinder does not support proper scoping yet. – Igor Raits Feb 07 '21 at 12:45

0 Answers0