From 5d0c84583fa4f534bda813432674184e38cf32c7 Mon Sep 17 00:00:00 2001 From: Augustina Ragwitz Date: Thu, 17 Mar 2016 17:12:01 -0700 Subject: [PATCH] Add Keystone project validation to quota and flavor management Currently, Nova does not check the validity of what the user provides for the project id value in quota and flavor management activities. This leads to inaccurate quota entries in the database, causing the user to think Nova isn't reporting quota information accurately. The solution proposed in this blueprint is to add project id validation specifically to quota and flavor management through Keystone, to provide the user with an error if their specified project id is invalid, and to ensure quota and flavor management data is not incorrectly modified. bp validate-project-with-keystone Previously-approved: kilo Change-Id: I631cef639e9485a36ab0e605aef0598f786332dc --- .../validate-tenant-user-with-keystone.rst | 281 ++++++++++++++++++ 1 file changed, 281 insertions(+) create mode 100644 specs/newton/approved/validate-tenant-user-with-keystone.rst diff --git a/specs/newton/approved/validate-tenant-user-with-keystone.rst b/specs/newton/approved/validate-tenant-user-with-keystone.rst new file mode 100644 index 000000000..98a0183c8 --- /dev/null +++ b/specs/newton/approved/validate-tenant-user-with-keystone.rst @@ -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