Add project validation via Keystone to quota and flavor management¶
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.
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.
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.
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.
Keystone will return one of the following results, which will be translated into a Nova response:
200 - project exists, Nova proceeds
404 - project does not exist, Nova returns a 400 bad response stating that no such project id has been found
403 - user does not have permissions to ask the question, we will process as if it succeeds but log that we didn’t have permissions to verify.
Anything else - something is way wrong. Nova will proceed as if it’s a success, but we will log the response as a warning.
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.
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:
None. This is using existing authorization mechanisms and doesn’t present any new logic.
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.
- Primary assignee:
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.
Tempest test cases, as well as Nova unit and functional test cases, will be created to verify project id verification.
Tempest test coverage:
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:
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:
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
Previous proposed code change: https://review.openstack.org/#/c/91866/
Customizing authorization: http://docs.openstack.org/trunk/openstack-ops/content/projects_users.html