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
Matt Riedemann
parent
e4480b2d24
commit
1b36e43c22
|
|
@ -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
|
||||
Loading…
Reference in New Issue