Merge "Add Keystone project validation to quota and flavor management"
This commit is contained in:
Jenkins
281
specs/newton/approved/validate-tenant-user-with-keystone.rst
Normal file
281
specs/newton/approved/validate-tenant-user-with-keystone.rst
Normal file
@@ -0,0 +1,281 @@
|
||||
..
|
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||
License.
|
||||
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
==================================================================
|
||||
Add project validation via Keystone to quota and flavor management
|
||||
==================================================================
|
||||
|
||||
https://blueprints.launchpad.net/nova/+spec/validate-project-with-keystone
|
||||
|
||||
When an administrator performs functions on other tenants, they have to specify
|
||||
a project id to identify the tenant. Nova does not currently check the validity
|
||||
of this administrator-provided project id.
|
||||
|
||||
The scope of this blueprint is to add project id validation to quota management
|
||||
(i.e. quota-defaults, quota-detail, quota-show, quota-update) and to flavor
|
||||
access management (i.e. flavor-access-add). Adding project id validation to any
|
||||
functionality outside of quota and flavor management is beyond the scope of
|
||||
this blueprint.
|
||||
|
||||
|
||||
Problem description
|
||||
===================
|
||||
|
||||
Nova quota sets management and flavor access management through the CLI require
|
||||
the administrator to specify a project id. Nothing actually checks if this
|
||||
project id actually exists, so a administrator can easily specify an invalid
|
||||
project.
|
||||
|
||||
If an invalid project id is provided to the quota-update command when updating
|
||||
the quota for a particular quota class, Nova reports unexpected quota
|
||||
information. The project id specified by the user ends up in the project_id
|
||||
field in the entry created in Nova's project_user_quotas table. When the
|
||||
project id does not match what is in the project_user_quotas table, invalid
|
||||
quotas are set. Any function performed on a project that has a quota check will
|
||||
not be affected the way the administrator expects.
|
||||
|
||||
For instance, if the administrator wants to increase the number of floating ip
|
||||
address for a given project id because that project has used all of its quota,
|
||||
and the wrong project id was provided to quota-update, any attempt to add
|
||||
additional floating ip addresses will unexpectedly fail. Historically,
|
||||
administrators debugging this issue have filed invalid bugs against Nova quota
|
||||
management.
|
||||
|
||||
|
||||
Use Cases
|
||||
----------
|
||||
|
||||
As an administrator, when I attempt to modify quota or flavor access
|
||||
information on one of my projects, and I accidentally provide an invalid
|
||||
project id:
|
||||
|
||||
* I want to know the project id I provided is invalid.
|
||||
|
||||
* I don't want my existing quota or flavor access data updated when I provide
|
||||
an invalid project id.
|
||||
|
||||
|
||||
Proposed change
|
||||
===============
|
||||
|
||||
Nova will use the requestor's user token to query Keystone. The Keystone
|
||||
response will determine access to the project and indicate if the project
|
||||
exists.
|
||||
|
||||
If the requestor passes the authorization check:
|
||||
|
||||
* if the project exists, they will recieve a 200 response
|
||||
|
||||
* if the project does not exist, they will receive a 404 response from
|
||||
Keystone, which becomes a 400 response in Nova.
|
||||
|
||||
If the requestor does not pass the authorization check, they will receive a 403
|
||||
response indicating they are not authorized to know whether or not the project
|
||||
exists.
|
||||
|
||||
Because this change is dependent on policy information being set correctly
|
||||
between Keystone and Nova, we need to provide guidance for operators setting
|
||||
this policy. This update will require a release note and a documentation
|
||||
update.
|
||||
|
||||
API changes will only be made to v2.1; API v2.0 is currently frozen.
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
||||
Status Quo: don't validate the project id and leave it up to the user to figure
|
||||
out the appropriate project id via "keystone tenant-list". This will continue
|
||||
to be a poor user experience for end users and the Nova team will continue to
|
||||
field bug reports on inaccurate quotas and flavor access values.
|
||||
|
||||
Another alternative is to have the python-novaclient validate the project id
|
||||
and expect other clients (e.g. third party) to do the same. This doesn't solve
|
||||
for the problem in Nova itself where invalid project id's end up in the
|
||||
database. It does make sense to have the CLI handle project name verification
|
||||
as this change would only apply to project id verification.
|
||||
|
||||
An alternative discussed during the cross-project session at the Newton summit
|
||||
was to use the Nova service user token to access the data from Keystone. This
|
||||
was dismissed because it obfuscates what users have access to what resources
|
||||
and could present a potential security risk.
|
||||
|
||||
Finally, another option explored in the past was simply doing UUID
|
||||
verification. This approach was rejected because we don't require project id's
|
||||
to be UUID's, so valid project id's would be rejected.
|
||||
|
||||
Data model impact
|
||||
-----------------
|
||||
|
||||
None. If any entries exist with the project_id set to an invalid id, they can
|
||||
be deleted using the relevant delete commands. Deletes should not trigger
|
||||
project id validation.
|
||||
|
||||
REST API impact
|
||||
---------------
|
||||
|
||||
Project id validation would create a new error condition for certain API
|
||||
methods.
|
||||
|
||||
If a Keystone service account exists to validate the project id, and the
|
||||
project id is invalid, the API will return an HTTPBadRequest from the POST and
|
||||
GET requests with error text.
|
||||
|
||||
The following API methods would be impacted:
|
||||
|
||||
* quota-defaults
|
||||
|
||||
* quota-detail
|
||||
|
||||
* quota-show
|
||||
|
||||
* quota-update
|
||||
|
||||
* flavor-access-add
|
||||
|
||||
Security impact
|
||||
---------------
|
||||
|
||||
None. This is using existing authorization mechanisms and doesn't present any
|
||||
new logic.
|
||||
|
||||
Notifications impact
|
||||
--------------------
|
||||
|
||||
None
|
||||
|
||||
Performance Impact
|
||||
------------------
|
||||
|
||||
There will be minor impact to performance. While a request to Keystone is
|
||||
required to validate the project id, it would be a low-frequency operation
|
||||
because quotas/flavor access are not often changed.
|
||||
|
||||
Other end user impact
|
||||
---------------------
|
||||
|
||||
Users will need documentation on how to configure their Keystone and Nova
|
||||
policy to take advantage of this update.
|
||||
|
||||
An attempt to show existing entries for an invalid project id will result in a
|
||||
400 error. Future work should provide users with a mechanism for cleaning up
|
||||
bad entries.
|
||||
|
||||
Other deployer impact
|
||||
---------------------
|
||||
|
||||
The quota and flavor operations should not be blocked if either Keystone does
|
||||
not exist or if the Keystone policy is not set up correctly for project id
|
||||
validation. In this case, a warning message should be logged indicating that
|
||||
project id validation is unavailable. This warning should be logged each time
|
||||
for improved visibility to the operator, so they can fix their policy.
|
||||
|
||||
Developer impact
|
||||
----------------
|
||||
None
|
||||
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
Primary assignee:
|
||||
auggy
|
||||
|
||||
Other contributors:
|
||||
thang-pham
|
||||
|
||||
Work Items
|
||||
----------
|
||||
|
||||
* Access the user token via the current context
|
||||
|
||||
* Implement methods to get the project by a given id.
|
||||
|
||||
* Modify QuotaSetsController class in nova/api/openstack/compute/quotas.py to
|
||||
validate the project id, if provided.
|
||||
|
||||
* Modify FlavorActionController class in
|
||||
nova/api/openstack/compute/flavor_access.py to validate the project id, if
|
||||
provided.
|
||||
|
||||
* Create tempest test cases and Nova unit and functional test cases to verify
|
||||
functionality.
|
||||
|
||||
* Update the Keystone DocImpact bug with policy examples so the documentation
|
||||
can be updated.
|
||||
|
||||
Dependencies
|
||||
============
|
||||
None
|
||||
|
||||
|
||||
Testing
|
||||
=======
|
||||
|
||||
Tempest test cases, as well as Nova unit and functional test cases, will be
|
||||
created to verify project id verification.
|
||||
|
||||
Tempest test coverage:
|
||||
|
||||
* Keystone validation
|
||||
|
||||
* A feature toggle in Tempest to tell it if Keystone is configured properly (in
|
||||
devstack) for the policy to work
|
||||
|
||||
Commands to be tested with validation:
|
||||
|
||||
* quota-defaults
|
||||
|
||||
* quota-detail
|
||||
|
||||
* quota-show
|
||||
|
||||
* quota-update
|
||||
|
||||
* flavor-access-add
|
||||
|
||||
Test cases for each command:
|
||||
|
||||
* valid project id - 200
|
||||
|
||||
* invalid project id - 400
|
||||
|
||||
* user has access to valid project - 200
|
||||
|
||||
* user does not have access to valid project - 403
|
||||
|
||||
* Keystone is unavailable - log warning
|
||||
|
||||
Commands to be tested with no validation:
|
||||
|
||||
* quota-delete
|
||||
|
||||
* flavor-access-delete
|
||||
|
||||
Test cases for each command:
|
||||
|
||||
* pre-existing invalid project id - 200
|
||||
|
||||
* new invalid project id - 200 (current behavior)
|
||||
|
||||
** a new entry should not be created and then deleted
|
||||
|
||||
Documentation Impact
|
||||
====================
|
||||
None
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
* Previous proposed code change: https://review.openstack.org/#/c/91866/
|
||||
* Reported bugs:
|
||||
https://bugs.launchpad.net/nova/+bug/1313935
|
||||
https://bugs.launchpad.net/nova/+bug/1317515
|
||||
https://bugs.launchpad.net/nova/+bug/1118066
|
||||
* Customizing authorization:
|
||||
http://docs.openstack.org/trunk/openstack-ops/content/projects_users.html
|
||||
Reference in New Issue
Block a user