be3c153d56
The instance_uuid handling on the detailed node information endpoint of the api (/v1/nodes/detail?instance_uuid=<uuid>), which is used by services such as Nova for explicit node status lookups, previously had special conditional logic surrounding it which skipped the inclusion of the API requestor project-id, from being incorporated into the database query. Ultimately, this allowed an authenticated user to obtain a partially redacted node entry where sensitive informational fields were scrubbed from the response payload. With this fix, queries for an explicit instance_uuid now follow the standard path inside the Ironic API to the database which includes inclusion of a requestor Project-ID if required by configured policy. Change-Id: I9bfa5a54e02c8a1e9c8cad6b9acdbad6ab62bef3 Story: 2008976 Task: 42620
21 lines
1.1 KiB
YAML
21 lines
1.1 KiB
YAML
---
|
|
security:
|
|
- |
|
|
Fixes an issue with the ``/v1/nodes/detail`` endpoint where an
|
|
authenticated user could explicitly ask for an ``instance_uuid`` lookup
|
|
and the associated node would be returned to the user with sensitive
|
|
fields redacted in the result payload if the user did not explicitly have
|
|
``owner`` or ``lessee`` permissions over the node. This is considered a
|
|
low-impact low-risk issue as it requires the API consumer to already know
|
|
the UUID value of the associated instance, and the returned information
|
|
is mainly metadata in nature. More information can be found in
|
|
`Storyboard story 2008976 <https://storyboard.openstack.org/#!/story/2008976>`_.
|
|
fixes:
|
|
- |
|
|
Fixes an issue with the ``/v1/nodes/detail`` endpoint where requests
|
|
for an explicit ``instance_uuid`` match would not follow the standard
|
|
query handling path and thus not be filtered based on policy determined
|
|
access level and node level ``owner`` or ``lessee`` fields appropriately.
|
|
Additional information can be found in
|
|
`story 2008976 <https://storyboard.openstack.org/#!/story/2008976>`_.
|