Events RBAC via Policy
OpenStack needs to support granular, customizable Role-Based Access Control (RBAC) for ceilometer events. Policy should be dependent on policy.json rather than simply hard-coded. APIImpact SecurityImpact UpgradeImpact Change-Id: Id25d154eac90e14c5501f806e81e04a059f5a836
This commit is contained in:
Matthew Edmonds
parent
9d5a57b45e
commit
917d20718b
214
specs/liberty/events-rbac.rst
Normal file
214
specs/liberty/events-rbac.rst
Normal file
@ -0,0 +1,214 @@
|
||||
..
|
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||
License.
|
||||
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
==========================================
|
||||
Events RBAC via Policy
|
||||
==========================================
|
||||
|
||||
OpenStack needs to support granular, customizable Role-Based Access Control
|
||||
(RBAC) for ceilometer events. Policy should be dependent on policy.json rather
|
||||
than simply hard-coded.
|
||||
|
||||
https://blueprints.launchpad.net/ceilometer/+spec/events-rbac
|
||||
|
||||
Problem description
|
||||
===================
|
||||
|
||||
The only RBAC validation for ceilometer’s /events REST API that is in place
|
||||
today is hard-coded logic to restrict requests to admins. This is not granular
|
||||
enough. In a multi-tenant environment, there must be provision to restrict data
|
||||
from events to the scope of the token given on the request (e.g. an admin from
|
||||
one project should not be able to view the events of another project). There
|
||||
should also be a way to allow non-admins access to some events (e.g. events
|
||||
for their resources). This issue was originally raised as a bug [1].
|
||||
|
||||
|
||||
Proposed change
|
||||
===============
|
||||
|
||||
This blueprint proposes the following changes in the behavior of ceilometer’s
|
||||
/events REST API:
|
||||
|
||||
Add the following rules to ceilometer’s default policy.json:
|
||||
|
||||
“telemetry:events:index”: “role:admin”
|
||||
“telemetry:events:show”: “role:admin”
|
||||
|
||||
Modify the code to uses those checks to determine who is allowed to request a
|
||||
list of events (index) or a specific event (show). This pattern is in line with
|
||||
other OpenStack projects.
|
||||
|
||||
Further modify the code to, if/when those checks pass, filter which events will be returned based on the scope of the token. If the token is for an admin user
|
||||
(determined by checking the special context_is_admin rule from policy.json),
|
||||
only return events corresponding to the project to which the supplied
|
||||
X-Auth-Token is scoped. This is also consistent with other projects. If the
|
||||
token is for a non-admin user, further filter the results to only return
|
||||
events corresponding to the user to which the supplied X-Auth-Token is scoped,
|
||||
as well as the project.
|
||||
|
||||
The events REST API will be processed only if the user passes a project-scoped
|
||||
token. This is required to filter the events based on the project. If the user
|
||||
passes an unscoped or domain-scoped token, a 403 error will be thrown.
|
||||
|
||||
There may be events for which no project/user information is recorded. Most if
|
||||
not all of these should have project/user information, so event-generating code
|
||||
will need to be modified to include that when creating future events. Updating
|
||||
existing events within the database is outside the scope of this spec. Until
|
||||
all events have project/user information, events which lack this data will be
|
||||
returned along with events corresponding to the token’s project, if the token's
|
||||
user is an admin on that project.
|
||||
|
||||
For the first implementation, common name-reserved traits will be used to store
|
||||
project/user information.
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
||||
We could use policy.json checks to filter results as well as determine whether
|
||||
the request is allowed. This does not fit with the role and purpose of
|
||||
policy.json, and may also have significant performance implications.
|
||||
|
||||
Storing project/user information in base attributes rather than traits was
|
||||
considered. This may be better long-term, but there has been some debate on the
|
||||
appropriateness of using base attributes if there will be some events that are
|
||||
not scoped to a project/user. Implementing this using traits first will help us
|
||||
determine whether that is a valid case. A switch to base attributes could come
|
||||
later.
|
||||
|
||||
Rather than return both project/user-scoped events and unscoped events in a
|
||||
single response, we could require a separate API call for unscoped events
|
||||
if/when that is what the user desires. E.g. /broadcasts instead of /events. As
|
||||
it is unclear whether we will end up with any events that do not have
|
||||
project/user information, considering this now would be premature.
|
||||
|
||||
We could create another policy check to identify whether a non-admin role
|
||||
should be considered an admin for the purpose of the /events API (and thus able
|
||||
query events for the entire project rather than just for themselves). But since
|
||||
it is expected that events will be split out of ceilometer like meters
|
||||
(gnocchi) and alarms (aodh), that would seem to be a short-term solution.
|
||||
|
||||
We could support domain-scoped tokens to allow domain admins to query events
|
||||
for the entire domain with a single request. This may be needed in the future,
|
||||
but does not appear to be something that must be done as part of this effort.
|
||||
And there could be benefits to waiting for the keystone reseller spec [2]
|
||||
implementation.
|
||||
|
||||
Data model impact
|
||||
-----------------
|
||||
|
||||
None, as long as we stick using traits.
|
||||
|
||||
REST API impact
|
||||
---------------
|
||||
|
||||
Whereas before this change an admin of any project saw events for EVERY project
|
||||
in the response to a GET /events request, now GET /events will filter out
|
||||
events belonging to projects other than the one in the scope of the request's
|
||||
auth token. This closes a security hole that allowed admins of one project to
|
||||
gain information about another project in which they have no role.
|
||||
|
||||
Security impact
|
||||
---------------
|
||||
|
||||
This will greatly enhance security by default. It will also provide a mechanism
|
||||
for operators to customize policy related to events, so operators taking
|
||||
advantage of this capability will need to consider the potential security
|
||||
impacts of their configuration changes.
|
||||
|
||||
Pipeline impact
|
||||
---------------
|
||||
|
||||
None
|
||||
|
||||
Other end user impact
|
||||
---------------------
|
||||
|
||||
None
|
||||
|
||||
Performance/Scalability Impacts
|
||||
-------------------------------
|
||||
|
||||
Filtering on project/user may have a slight negative performance impact, though
|
||||
this should be offset by the likely much more substantial performance
|
||||
improvement of returning less data to the caller.
|
||||
|
||||
Allowing events that do not have project/user information via the same API
|
||||
queries will mean making two internal calls (one to get events scoped to the
|
||||
project/user and another to get events not scoped to a project/user) and then
|
||||
merging them. This may have a slight negative performance impact.
|
||||
|
||||
Other deployer impact
|
||||
---------------------
|
||||
|
||||
Updating from a previous release will need to include moving to a new version
|
||||
of policy.json including the new checks, else those would resolve to the
|
||||
default which is to allow for anyone.
|
||||
|
||||
Developer impact
|
||||
----------------
|
||||
|
||||
None
|
||||
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
Primary assignee:
|
||||
edmondsw
|
||||
|
||||
Other contributors:
|
||||
dikonoor
|
||||
|
||||
Work Items
|
||||
----------
|
||||
|
||||
* Check context_is_admin to determine appropriate response filtering
|
||||
* Check policy.json to determine whether the request is allowed
|
||||
* Add project/user to events that are currently lacking those details
|
||||
|
||||
|
||||
Future lifecycle
|
||||
================
|
||||
|
||||
This is essentially a large bug fix, not a feature. As such, all members of the
|
||||
Telemetry program will be expected to keep this from breaking again.
|
||||
|
||||
Several potential future enhancements are discussed under the Alternatives
|
||||
section. It is expected that those would require a separate spec if someone
|
||||
wants to pick up any of them in the future.
|
||||
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
None
|
||||
|
||||
|
||||
Testing
|
||||
=======
|
||||
|
||||
Unit tests should be sufficient.
|
||||
|
||||
|
||||
Documentation Impact
|
||||
====================
|
||||
|
||||
Developer documentation [3] will be updated to add user_id to the list of
|
||||
default traits, and to explain that non-admins will only be able to view events
|
||||
with their user_id, while admins will only be able to view events with their
|
||||
tenant_id plus events not associated with a project (aka tenant).
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
[1] https://bugs.launchpad.net/ceilometer/+bug/1461767
|
||||
[2] https://github.com/openstack/keystone-specs/blob/master/specs/liberty/reseller.rst
|
||||
[3] http://docs.openstack.org/developer/ceilometer/events.html
|
||||
|
||||
Loading…
Reference in New Issue
Block a user