0313ce26b5
Turns out the service role support doesn't quite work, because you could not enumerate nodes regardless of node owner or lessee in order to enable services like Nova to enumerate nodes to be able to schedule upon them, or networking-baremetal to enumerate ports in update mapping in Neutron. So this change enables permissions to be modified to allow service project users with the service role to enumerate the list of resources, and grants rights similar to "system scoped members" to the service project's users with the "service" role which aligns with update actions to provision/unprovision nodes. Adds some additional rbac testing to ensure we appropriately covered these access rights. Closes-Bug: 2051592 Change-Id: I2b4bcc748b6e43e4215dc45137becce301349032
42 lines
2.0 KiB
YAML
42 lines
2.0 KiB
YAML
---
|
|
fixes:
|
|
- |
|
|
Provides a fix for ``service`` role support to enable the use
|
|
case where a dedicated service project is used for cloud service
|
|
operation to facilitate actions as part of the operation of the
|
|
cloud infrastructure.
|
|
|
|
OpenStack clouds can take a variety of configuration models
|
|
for service accounts. It is now possible to utilize the
|
|
``[DEFAULT] rbac_service_role_elevated_access`` setting to
|
|
enable users with a ``service`` role in a dedicated ``service``
|
|
project to act upon the API similar to a "System" scoped
|
|
"Member" where resources regardless of ``owner`` or ``lessee``
|
|
settings are available. This is needed to enable synchronization
|
|
processes, such as ``nova-compute`` or the ``networking-baremetal``
|
|
ML2 plugin to perform actions across the whole of an Ironic
|
|
deployment, if desirable where a "System" scoped user is also
|
|
undesirable.
|
|
|
|
This functionality can be tuned to utilize a customized project
|
|
name aside from the default convention ``service``, for example
|
|
``baremetal`` or ``admin``, utilizing the
|
|
``[DEFAULT] rbac_service_project_name`` setting.
|
|
|
|
Operators can alternatively entirely override the
|
|
``service_role`` RBAC policy rule, if so desired, however
|
|
Ironic feels the default is both reasonable and delineates
|
|
sufficiently for the variety of Role Based Access Control
|
|
usage cases which can exist with a running Ironic deployment.
|
|
upgrades:
|
|
- |
|
|
This version of ironic includes an opt-in fix to the Role Based Access
|
|
Control logic where the "service" role in a "service" project is
|
|
able to be granted elevated access to the API surface of Ironic such that
|
|
all baremetal nodes are visible to that API consumer. This is for
|
|
deployments which have not moved to a "System" scoped user for connecting
|
|
to ironic for services like ``nova-compute`` and the
|
|
``networking-baremetal`` Neutron plugin, and where it is desirable for
|
|
those services to be able to operate across the whole of the Ironic
|
|
deployment.
|