3c524e6491
Now that we have system scope in place, we should make sure at least one user has a role assignment on the system. We can do this at the same time we grant the user a role on a project during bootstrap. This is backwards compatible because even if a deployment doesn't use system-scope, the assignment will just sit there. The deployment will have to opt into enforcing scope by updating configuration options for oslo.policy to enforce scoping. This shouldn't prevent deployments from fixing bug 968696 and using system scope. Closes-Bug: 1749268 Change-Id: I6b7196a28867d9a699716c8fef2609d608a5b2a2
22 lines
1.2 KiB
YAML
22 lines
1.2 KiB
YAML
---
|
|
features:
|
|
- |
|
|
[`blueprint system-scope <https://blueprints.launchpad.net/keystone/+spec/system-scope>`_]
|
|
Keystone now supports the ability to assign roles to users and groups on
|
|
the system. As a result, users and groups with system role assignment will
|
|
be able to request system-scoped tokens. Additional logic has been added to
|
|
``keystone-manage bootstrap`` to ensure the administrator has a role on the
|
|
project and system.
|
|
fixes:
|
|
- |
|
|
[`bug 968696 <https://bugs.launchpad.net/keystone/+bug/968696>`_]
|
|
The work to introduce `system-scope <https://blueprints.launchpad.net/keystone/+spec/system-scope>`_
|
|
in addition to associating `scope types <http://specs.openstack.org/openstack/oslo-specs/specs/queens/include-scope-in-policy.html>`_
|
|
to operations with ``oslo.policy`` will give project developers the ability
|
|
to fix `bug 968696 <https://bugs.launchpad.net/keystone/+bug/968696>`_.
|
|
- |
|
|
[`bug 1749268 <https://bugs.launchpad.net/keystone/+bug/1749268>`_]
|
|
The ``keystone-manage bootstrap`` command now ensures that an administrator
|
|
has a system role assignment. This prevents the ability for operators to
|
|
lock themselves out of system-level APIs.
|