Common Policy Engine Implementation
Policies can be expressed in one of two forms: A list of lists, or a string written in the new policy language.
In the list-of-lists representation, each check inside the innermost list is combined as with an “and” conjunction–for that check to pass, all the specified checks must pass. These innermost lists are then combined as with an “or” conjunction. This is the original way of expressing policies, but there now exists a new way: the policy language.
In the policy language, each check is specified the same way as in the list-of-lists representation: a simple “a:b” pair that is matched to the correct code to perform that check. However, conjunction operators are available, allowing for more expressiveness in crafting policies.
As an example, take the following rule, expressed in the list-of-lists representation:
[["role:admin"], ["project_id:%(project_id)s", "role:projectadmin"]]
In the policy language, this becomes:
role:admin or (project_id:%(project_id)s and role:projectadmin)
The policy language also has the “not” operator, allowing a richer policy rule:
project_id:%(project_id)s and not role:dunce
It is possible to perform policy checks on the following user attributes (obtained through the token): user_id, domain_id or project_id:
domain_id:<some_value>
Attributes sent along with API calls can be used by the policy engine (on the right side of the expression), by using the following syntax:
<some_value>:user.id
Contextual attributes of objects identified by their IDs are loaded from the database. They are also available to the policy engine and can be checked through the target keyword:
<some_value>:target.role.name
All these attributes (related to users, API calls, and context) can be checked against each other or against constants, be it literals (True, <a_number>) or strings.
Finally, two special policy checks should be mentioned; the policy check “@” will always accept an access, and the policy check ”!” will always reject an access. (Note that if a rule is either the empty list (“[]”) or the empty string, this is equivalent to the “@” policy check.) Of these, the ”!” policy check is probably the most useful, as it allows particular rules to be explicitly disabled.
Bases: openstack_dashboard.openstack.common.policy.BaseCheck
Implements the “and” logical operator.
A policy check that requires that a list of other checks all return True.
Adds rule to be tested.
Allows addition of another rule to the list of rules that will be tested. Returns the AndCheck object for convenience.
Bases: object
Abstract base class for Check classes.
Bases: openstack_dashboard.openstack.common.policy.BaseCheck
A base class to allow for user-defined policy checks.
Bases: object
Responsible for loading and enforcing rules.
Parameters: |
|
---|
Clears Enforcer rules, policy’s cache and policy’s path.
Checks authorization of a rule against the target and credentials.
Parameters: |
|
---|---|
Returns: | Returns False if the policy does not allow the action and exc is not provided; otherwise, returns a value that evaluates to True. Note: for rules using the “case” expression, this True value will be the specified string from the expression. |
Loads policy_path’s rules.
Policy file is cached and will be reloaded if modified.
Parameters: | force_reload – Whether to overwrite current rules. |
---|
Create a new Rules object based on the provided dict of rules.
Parameters: |
|
---|
Bases: openstack_dashboard.openstack.common.policy.BaseCheck
A policy check that always returns False (disallow).
Bases: openstack_dashboard.openstack.common.policy.Check
Bases: openstack_dashboard.openstack.common.policy.Check
Bases: openstack_dashboard.openstack.common.policy.BaseCheck
Implements the “not” logical operator.
A policy check that inverts the result of another policy check.
Bases: openstack_dashboard.openstack.common.policy.BaseCheck
Implements the “or” operator.
A policy check that requires that at least one of a list of other checks returns True.
Adds rule to be tested.
Allows addition of another rule to the list of rules that will be tested. Returns the OrCheck object for convenience.
Bases: object
Implement the core of parsing the policy language.
Uses a greedy reduction algorithm to reduce a sequence of tokens into a single terminal, the value of which will be the root of the Check tree.
Note: error reporting is rather lacking. The best we can get with this parser formulation is an overall “parse failed” error. Fortunately, the policy language is simple enough that this shouldn’t be that big a problem.
Perform a greedy reduction of the token stream.
If a reducer method matches, it will be executed, then the reduce() method will be called recursively to search for any more possible reductions.
Obtain the final result of the parse.
Raises ValueError if the parse failed to reduce to a single result.
Adds one more token to the state. Calls reduce().
Bases: type
Metaclass for the ParseState class.
Facilitates identifying reduction methods.
Bases: exceptions.Exception
Bases: openstack_dashboard.openstack.common.policy.Check
Bases: openstack_dashboard.openstack.common.policy.Check
Bases: dict
A store for rules. Handles the default_rule setting directly.
Allow loading of JSON rule data.
Bases: openstack_dashboard.openstack.common.policy.BaseCheck
A policy check that always returns True (allow).
Parses a policy rule into a tree of Check objects.
Decorator for reduction methods.
Arguments are a sequence of tokens, in order, which should trigger running this reduction method.
Register a function or Check class as a policy check.
Parameters: |
|
---|