Add spec for user_id base policy enforcement
This was a feature from Nova legacy API codebase that had 0 testing, and only hints of documentation. This proposes to bring it back in a very limited (and deprecated way) for the current code. Change-Id: I70a8c8e76f234611f4b2972b3adae86ca09da012
This commit is contained in:
Sean Dague
committed by
Matt Riedemann
Matt Riedemann
parent
e4480b2d24
commit
1b36e43c22
228
specs/newton/approved/user_id_based_policy_enforcement.rst
Normal file
228
specs/newton/approved/user_id_based_policy_enforcement.rst
Normal file
@@ -0,0 +1,228 @@
|
|||||||
|
..
|
||||||
|
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||||
|
License.
|
||||||
|
|
||||||
|
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||||
|
|
||||||
|
================================
|
||||||
|
User_id based policy enforcement
|
||||||
|
================================
|
||||||
|
|
||||||
|
https://blueprints.launchpad.net/nova/+spec/user_id_based_policy_enforcement
|
||||||
|
|
||||||
|
Policy.json is a turing complete ball of confusion. Only the brave
|
||||||
|
dare to wander through it's halls. Only the fortunate come out
|
||||||
|
unscathed. No one has truly explored what can be created from this
|
||||||
|
beast, and we discover new wonders every day.
|
||||||
|
|
||||||
|
|
||||||
|
Problem description
|
||||||
|
===================
|
||||||
|
|
||||||
|
In the legacy v2 Nova API code base, it turned out there was a back
|
||||||
|
door feature by which operations could be scoped to 'user_id' instead
|
||||||
|
of 'project_id'. No one on the Nova team realized this was a thing. It
|
||||||
|
was not baked into the current Nova API stack, which started being
|
||||||
|
worked on 3 years ago.
|
||||||
|
|
||||||
|
As is the great promise of all software, if a feature/bug exists, and
|
||||||
|
is shipped, eventually someone will make it critical to their use of
|
||||||
|
that software.
|
||||||
|
|
||||||
|
In this case this was used as a backdoor to the lack of hierarchical
|
||||||
|
projects. That should be the real solution here. And it is also clear
|
||||||
|
based on this feature use that simple 1 level of nesting of
|
||||||
|
hierarchical projects with only quota accounted at the top level, is
|
||||||
|
sufficient for many people's needs.
|
||||||
|
|
||||||
|
The way this was used was to put large sets of users (~150) into a
|
||||||
|
single project, with one quota for them all, but not allow users to
|
||||||
|
manipulate each other's servers.
|
||||||
|
|
||||||
|
This spec proposes that we support a very limited set of operations on
|
||||||
|
servers to check the user_id of the server in policy. These are
|
||||||
|
operations that are considered destructive to servers.
|
||||||
|
|
||||||
|
Use Cases
|
||||||
|
---------
|
||||||
|
|
||||||
|
Large deployments, like CERN, find it cumbersome to create keystone
|
||||||
|
projects for every single effort that has a different group of
|
||||||
|
people. For these more ephemeral efforts they create large "catchall"
|
||||||
|
projects and put users in them.
|
||||||
|
|
||||||
|
These users are working on different things, are not collaborating in
|
||||||
|
the traditional boundaries we expect within a keystone project, and
|
||||||
|
may not even know who else is in their "project". As such they want to
|
||||||
|
prevent users from accidentally destroying each others work. This was
|
||||||
|
done by updating policy to constrain many operations to user_id scoped
|
||||||
|
instead of project_id scoped.
|
||||||
|
|
||||||
|
.. note::
|
||||||
|
|
||||||
|
This goes wildly against the designed permissions model in
|
||||||
|
OpenStack. We really don't want this feature in Nova, and we don't
|
||||||
|
want it used. This spec is entirely a shim until basic hierarchical
|
||||||
|
project support exists, after which it will be removed.
|
||||||
|
|
||||||
|
Proposed change
|
||||||
|
===============
|
||||||
|
|
||||||
|
The following operations will be checked in policy taking the user_id
|
||||||
|
into account (if configured in policy.json).
|
||||||
|
|
||||||
|
* DELETE /servers/{server_id} - destructive
|
||||||
|
* PUT /servers/{server_id} - lets you change server name
|
||||||
|
|
||||||
|
As well as the following server actions:
|
||||||
|
* changePassword
|
||||||
|
* lock
|
||||||
|
* pause
|
||||||
|
* rebuild
|
||||||
|
* resize
|
||||||
|
* rescue
|
||||||
|
* os-stop
|
||||||
|
* suspend
|
||||||
|
* evacuate
|
||||||
|
* forceDelete
|
||||||
|
* shelve
|
||||||
|
* crashDump
|
||||||
|
|
||||||
|
These are considered destructive actions. Other, only disruptive,
|
||||||
|
actions such as `reboot` will be allowed. Also other security
|
||||||
|
exposures such as `show console` won't be addressed. The boundary for
|
||||||
|
security in OpenStack is a `project`. This is just a safe guard for
|
||||||
|
some server destructive behavior that existing sites are concerned
|
||||||
|
about. This list of actions was `acknowledged`_ as sufficient by key
|
||||||
|
stake holders (such as CERN) that spoke up with the initial issue.
|
||||||
|
|
||||||
|
This will be added as a deprecated construct, and will be removed in
|
||||||
|
the future. It should give people some time to migrate away to other
|
||||||
|
models, and realize this is not going to be supported in the
|
||||||
|
future. This kind of change introduces an interop problem, which is
|
||||||
|
why it will be discouraged from use.
|
||||||
|
|
||||||
|
The eventual solution will be hierarchical projects. As seen from this
|
||||||
|
use case, many uses of hierarchical projects only need quota at the top
|
||||||
|
level. As such, that should be considered a first pass before working
|
||||||
|
out hierarchical quotas.
|
||||||
|
|
||||||
|
Alternatives
|
||||||
|
------------
|
||||||
|
|
||||||
|
Do nothing. This is somewhat of a fringe feature.
|
||||||
|
|
||||||
|
Data model impact
|
||||||
|
-----------------
|
||||||
|
|
||||||
|
None.
|
||||||
|
|
||||||
|
REST API impact
|
||||||
|
---------------
|
||||||
|
|
||||||
|
This changes the way we do policy enforcement in a series of API
|
||||||
|
calls.
|
||||||
|
|
||||||
|
For deployments that choose to do this, they should realize that they
|
||||||
|
are breaking the basic interop construct that permissions for all
|
||||||
|
server constructs are a project level permissions construct. It would
|
||||||
|
be great to have some Tempest tests to check for this.
|
||||||
|
|
||||||
|
Security impact
|
||||||
|
---------------
|
||||||
|
|
||||||
|
We are explicitly not handling all the security sensitive API
|
||||||
|
points. This is only to prevent the worse accident destruction of
|
||||||
|
resources (like the fact that ``rm -rf /`` no longer actually does the
|
||||||
|
scary thing).
|
||||||
|
|
||||||
|
Users operating within the same project should be considered
|
||||||
|
collaborative multi taskers, and can access each others resources.
|
||||||
|
|
||||||
|
Notifications impact
|
||||||
|
--------------------
|
||||||
|
|
||||||
|
None.
|
||||||
|
|
||||||
|
Other end user impact
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
In the default case, None.
|
||||||
|
|
||||||
|
Performance Impact
|
||||||
|
------------------
|
||||||
|
|
||||||
|
None. All the data needed for the policy checks is already there.
|
||||||
|
|
||||||
|
Other deployer impact
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
In the default case, None.
|
||||||
|
|
||||||
|
Because deployers were using this feature of the legacy v2 stack in
|
||||||
|
Liberty, we should consider backporting this to Mitaka and possibly
|
||||||
|
liberty to smooth the transition.
|
||||||
|
|
||||||
|
Developer impact
|
||||||
|
----------------
|
||||||
|
|
||||||
|
None.
|
||||||
|
|
||||||
|
Implementation
|
||||||
|
==============
|
||||||
|
|
||||||
|
Assignee(s)
|
||||||
|
-----------
|
||||||
|
|
||||||
|
Primary assignee:
|
||||||
|
Ghanshyam Mann <ghanshyam.mann@nectechnologies.in>
|
||||||
|
|
||||||
|
Work Items
|
||||||
|
----------
|
||||||
|
|
||||||
|
* Implement policy checks for the listed calls above
|
||||||
|
* Implement custom policy testing for each of those calls
|
||||||
|
* Backport to Mitaka
|
||||||
|
* Potentially backport to Liberty
|
||||||
|
|
||||||
|
|
||||||
|
Dependencies
|
||||||
|
============
|
||||||
|
|
||||||
|
None.
|
||||||
|
|
||||||
|
Testing
|
||||||
|
=======
|
||||||
|
|
||||||
|
This will all be tested in tree with unit / functional testing and a
|
||||||
|
custom policy using `user_id` rules. There is currently no testing
|
||||||
|
which is why we removed this backdoor feature and did not notice.
|
||||||
|
|
||||||
|
Documentation Impact
|
||||||
|
====================
|
||||||
|
|
||||||
|
We should at the same time delete all references to using `user_id`
|
||||||
|
based policies for Nova from any OpenStack documentation, so that new
|
||||||
|
people do not start using this.
|
||||||
|
|
||||||
|
The only exception being `keypairs`, which has always been a bit of
|
||||||
|
an oddball element in Nova.
|
||||||
|
|
||||||
|
References
|
||||||
|
==========
|
||||||
|
|
||||||
|
* OpenStack Operators Discussion -
|
||||||
|
http://lists.openstack.org/pipermail/openstack-operators/2016-May/010526.html
|
||||||
|
|
||||||
|
.. _acknowledged: http://lists.openstack.org/pipermail/openstack-dev/2016-June/096590.html
|
||||||
|
|
||||||
|
History
|
||||||
|
=======
|
||||||
|
|
||||||
|
.. list-table:: Revisions
|
||||||
|
:header-rows: 1
|
||||||
|
|
||||||
|
* - Release Name
|
||||||
|
- Description
|
||||||
|
* - Newton
|
||||||
|
- Introduced
|
||||||
Reference in New Issue
Block a user