Rest API Policy Enforcement¶

Enforcement policy at REST API layer¶

The policy should be only enforced at REST API layer. This is clear for user to know where the policy will be enforced. If the policy spread into multiple layer of nova code, user won’t know when and where the policy will be enforced if they didn’t have knowledge about nova code.

Remove all the permission checking under REST API layer. Policy will only be enforced at REST API layer.

This will affect the EC2 API and V2.1 API, there are some API just have policy enforcement at Compute/Network API layer, those policy will be move to API layer and renamed.

Removes hard-code permission checks¶

Hard-coded permission checks make it impossible to supply a configurable policy. They should be removed in order to make nova auth completely configurable.

This will affect EC2 API and Nova V2.1 API. User need update their policy rule to match the old hard-code permission.

For Nova V2 API, the hard-code permission checks will be moved to REST API layer to guarantee it won’t break the back-compatibility. That may ugly some hard-code permission check in API layer, but V2 API will be removed once V2.1 API ready, so our choice will reduce the risk.

Port policy.d into nova¶

This feature make deployer can override default policy rule easily. And When nova default policy config changed, deployer only need replace default policy config files with new one. It won’t affect his own policy config in other files.

Use different prefix in policy rule name for EC2/V2/V2.1 API¶

Currently all the APIs(Nova v2/v2.1 API, EC2 API) use same set of policy rules. Especially there isn’t obvious mapping between those policy rules and EC2 API. User can know clearly which policy should be configured for specific API.

Nova should provide different prefix for policy rule name that used to group them, and put them in different policy configure file in policy.d

• EC2 API: Use prefix “ec2_api”. The rule looks like “ec2_api:[action]”
• Nova V2 API: After we move to V2.1, we needn’t spend time to change V2 api rule, and needn’t to bother deployer upgrade their policy config. So just keep V2 API policy rule named as before.
• Nova V2.1 API: We name the policy rule as “os_compute_api:[extension]:[action]”. The core API may be changed in the future, so we needn’t name them as “compute” or “compute_extension” to distinguish the core or extension API.

This will affect EC2 API and V2.1 API. For EC2 API, it need deployer update their policy config. For V2.1 API, there isn’t any user yet, so there won’t any effect.

Group the policy rules into different policy files¶

After group the policy rules for different API, we can separate them into different files. Then deployer will more clear for which rule he can set for specific API. The rules can be grouped as below:

• policy.json: It only contains the generic rule, like:

  "context_is_admin":  "role:admin",
  "admin_or_owner":  "is_admin:True or project_id:%(project_id)s",
  "default": "rule:admin_or_owner",
  

• policy.d/00-ec2-api.conf: It contains all the policy rules for EC2 API.

• policy.d/00-v2-api.conf: It contains all the policy rules for nova V2 API.

• policy.d/00-v2.1-api.conf: It contains all the policy rules for nova v2.1 API.

The prefix ‘00-‘ is used to order the configure file. All the files in policy.d will be loaded by alphabetical order. ‘00-‘ means those files will be loaded very early.