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.

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.

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:

sdague

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