OpenStack How to Customize Authorization (Policies, Policy.json)

Customizing Authorization

The default authorization settings only allow administrative users to create resources on behalf of a different project. OpenStack handles two kind of authorization policies:

• Operation-based: policies specify access criteria for specific operations, possibly with fine-grained control over specific attributes.
• Resource-based: whether access to a specific resource might be granted or not according to the permissions configured for the resource (currently available only for the network resource). The actual authorization policies enforced in an OpenStack service vary from deployment to deployment.

The policy engine reads entries from the policy.json file. The actual location of this file might vary from distribution to distribution, for nova it is typically in /etc/nova/policy.json. You can update entries while the system is running, and you do not have to restart services. Currently the only way of updating such policies is to edit the policy file.
The OpenStack service's policy engine matches a policy directly. A rule indicates evaluation of the elements of such policies. For instance, in a compute:create: [["rule:admin_or_owner"]] statement, the policy is compute:create, and the rule is admin_or_owner.
Policies are triggered by an OpenStack policy engine whenever one of them matches an OpenStack API operation or a specific attribute being used in a given operation. For instance, the engine tests the create:compute policy every time a user sends a POST /v2/{tenant_id}servers request to the OpenStack Compute API server. Policies can be also related to specific API extensions. For instance, if a user needs an extension like compute_extension:rescue the attributes defined by the provider extensions trigger the rule test for that operation.
An authorization policy can be composed by one or more rules. If more rules are specified, evaluation policy will be successful if any of the rules evaluates successfully; if an API operation matches multiple policies, then all the policies must evaluate successfully. Also, authorization rules are recursive. Once a rule is matched, the rule(s) can be resolved to another rule, until a terminal rule is reached. These are the rules defined:

• Role-based rules: evaluate successfully if the user submitting the request has the specified role. For instance "role:admin" is successful if the user submitting the request is an administrator.
• Field-based rules: evaluate successfully if a field of the resource specified in the current request matches a specific value. For instance "field:networks:shared=True" is successful if the attribute shared of the network resource is set to true.
• Generic rules: compare an attribute in the resource with an attribute extracted from the user's security credentials and evaluates successfully if the comparison is successful. For instance "tenant_id:%(tenant_id)s" is successful if the tenant identifier in the resource is equal to the tenant identifier of the user submitting the request.

Here are snippets of the default nova policy.json file:

{
 "context_is_admin":  [["role:admin"]],
 "admin_or_owner":  [["is_admin:True"], ["project_id:%(project_id)s"]], [1]
 "default": [["rule:admin_or_owner"]], [2]
 "compute:create": [],
 "compute:create:attach_network": [],
 "compute:create:attach_volume": [],
 "compute:get_all": [],
    "admin_api": [["is_admin:True"]],
 "compute_extension:accounts": [["rule:admin_api"]],
 "compute_extension:admin_actions": [["rule:admin_api"]],
 "compute_extension:admin_actions:pause": [["rule:admin_or_owner"]],
 "compute_extension:admin_actions:unpause": [["rule:admin_or_owner"]],
 "compute_extension:admin_actions:suspend": [["rule:admin_or_owner"]],
 "compute_extension:admin_actions:resume": [["rule:admin_or_owner"]],
 ...
 "compute_extension:admin_actions:migrate": [["rule:admin_api"]],
 "compute_extension:aggregates": [["rule:admin_api"]],
 "compute_extension:certificates": [],
 "compute_extension:cloudpipe": [["rule:admin_api"]],
 ...
 "compute_extension:flavorextraspecs": [],
 "compute_extension:flavormanage": [["rule:admin_api"]],  [3]
 }
 

[1] Shows a rule which evaluates successfully if the current user is an administrator or the owner of the resource specified in the request (tenant identifier is equal).
[2] Shows the default policy which is always evaluated if an API operation does not match any of the policies in policy.json.
[3] Shows a policy restricting the ability of manipulating flavors to administrators using the Admin API only.
In some cases, some operations should be restricted to administrators only. Therefore, as a further example, let us consider how this sample policy file could be modified in a scenario where we enable users to create their own flavors:

"compute_extension:flavormanage": [ ],

Copied From :
http://docs.openstack.org/trunk/openstack-ops/content/customize_auth.html

Ref Sites:
https://ask.openstack.org/en/question/2032/create-admin-user-within-single-tenant/
http://docs.openstack.org/trunk/openstack-ops/content/projects_users.html
http://docs.openstack.org/developer/keystone/architecture.html#approach-to-authorization-policy
http://knowledgestack.wordpress.com/2012/01/27/rbac-keystone-and-openstack/ <=== IMP

Fav Sites:
http://prosuncsedu.wordpress.com/2013/10/01/adding-enforcing-policy-in-openstack-nova-code/
http://prosuncsedu.wordpress.com/2013/09/28/policy-administration-for-openstack-nova/
http://prosuncsedu.wordpress.com/2013/09/18/change-policy-to-add-permission-to-an-existing-nova-command/
http://prosuncsedu.wordpress.com/tag/policy/