API

oslo_policy.policy

Common Policy Engine Implementation

Policies are expressed as a target and an associated rule:

"<target>": "<rule>"

The target is specific to the service that is conducting policy enforcement. Typically, the target refers to an API call.

A rule is made up of zero or more checks, where zero checks will always allow the action that is being enforced. A number of different check types are supported, which can be divided into generic checks and special checks.

Generic Checks

A generic check is used to perform matching against attributes that are sent along with the API calls. These attributes can be used by the policy engine (on the right side of the expression), by using the following syntax:

<some_attribute>:%(user.id)s

The value on the right-hand side is either a string or resolves to a string using regular Python string substitution. The available attributes and values are dependent on the program that is using the common policy engine.

All of these attributes (related to users, API calls, and context) can be checked against each other or against constants. It is important to note that these attributes are specific to the service that is conducting policy enforcement.

Generic checks can be used to perform policy checks on the following user attributes obtained through a token:

• user_id
• domain_id or project_id (depending on the token scope)
• list of roles held for the given token scope

For example, a check on the user_id would be defined as:

user_id:<some_value>

Together with the previously shown example, a complete generic check would be:

user_id:%(user.id)s

It is also possible to perform checks against other attributes that represent the credentials. This is done by adding additional values to the creds dict that is passed to the enforce() method.

Special Checks

Special checks allow for more flexibility than is possible using generic checks. The built-in special check types are role, rule, and http checks.

Role Check

A role check is used to check if a specific role is present in the supplied credentials. A role check is expressed as:

"role:<role_name>"

Rule Check

A rule check is used to reference another defined rule by its name. This allows for common checks to be defined once as a reusable rule, which is then referenced within other rules. It also allows one to define a set of checks as a more descriptive name to aid in readabilty of policy. A rule check is expressed as:

"rule:<rule_name>"

The following example shows a role check that is defined as a rule, which is then used via a rule check:

"admin_required": "role:admin"
"<target>": "rule:admin_required"

HTTP Check

An http check is used to make an HTTP request to a remote server to determine the results of the check. The target and credentials are passed to the remote server for evaluation. The action is authorized if the remote server returns a response of True. An http check is expressed as:

"http:<target URI>"

It is expected that the target URI contains a string formatting keyword, where the keyword is a key from the target dictionary. An example of an http check where the name key from the target is used to construct the URL is would be defined as:

"http://server.test/%(name)s"

Registering New Special Checks

It is also possible for additional special check types to be registered using the register() function.

Policy Rule Expressions

Policy rules 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. As an example, take the following rule, expressed in the list-of-lists representation:

[["role:admin"], ["project_id:%(project_id)s", "role:projectadmin"]]

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 class to perform that check:

TYPE	SYNTAX
User’s Role	role:admin
Rules already defined on policy	rule:admin_required
Against URLs¹	http://my-url.org/check
User attributes²	project_id:%(target.project.id)s
Strings	<variable>:’xpto2035abc’ ‘myproject’:<variable>
Literals	project_id:xpto2035abc domain_id:20 True:%(user.enabled)s

¹URL checking must return True to be valid

²User attributes (obtained through the token): user_id, domain_id or project_id

Conjunction operators are available, allowing for more expressiveness in crafting policies. So, in the policy language, the previous check in list-of-lists 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

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.

Default Rule

A default rule can be defined, which will be enforced when a rule does not exist for the target that is being checked. By default, the rule associated with the rule name of default will be used as the default rule. It is possible to use a different rule name as the default rule by setting the policy_default_rule configuration setting to the desired rule name.

class oslo_policy.policy.Enforcer(conf, policy_file=None, rules=None, default_rule=None, use_conf=True, overwrite=True)

Responsible for loading and enforcing rules.

Parameters:

• conf – A configuration object.
• policy_file – Custom policy file to use, if none is specified, conf.policy_file will be used.
• rules – Default dictionary / Rules to use. It will be considered just in the first instantiation. If load_rules() with force_reload=True, clear() or set_rules() with overwrite=True is called this will be overwritten.
• default_rule – Default rule to use, conf.default_rule will be used if none is specified.
• use_conf – Whether to load rules from cache or config file.
• overwrite – Whether to overwrite existing rules when reload rules from config file.

clear()

Clears Enforcer rules, policy’s cache and policy’s path.

enforce(rule, target, creds, do_raise=False, exc=None, *args, **kwargs)

Checks authorization of a rule against the target and credentials.

Parameters:

• rule (string or BaseCheck) – The rule to evaluate.
• target (dict) – As much information about the object being operated on as possible.
• creds (dict) – As much information about the user performing the action as possible.
• do_raise – Whether to raise an exception or not if check fails.
• exc – Class of the exception to raise if the check fails. Any remaining arguments passed to enforce() (both positional and keyword arguments) will be passed to the exception class. If not specified, PolicyNotAuthorized will be used.

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.

load_rules(force_reload=False)

Loads policy_path’s rules.

Policy file is cached and will be reloaded if modified.

Parameters:force_reload – Whether to reload rules from config file.

set_rules(rules, overwrite=True, use_conf=False)

Create a new Rules based on the provided dict of rules.

Parameters:

• rules (dict) – New rules to use.
• overwrite – Whether to overwrite current rules or update them with the new rules.
• use_conf – Whether to reload rules from cache or config file.

exception oslo_policy.policy.PolicyNotAuthorized(rule, target, creds)

Default exception raised for policy enforcement failure.

class oslo_policy.policy.Rules(rules=None, default_rule=None)

A store for rules. Handles the default_rule setting directly.

classmethod from_dict(rules_dict, default_rule=None)

Allow loading of rule data from a dictionary.

classmethod load_json(data, default_rule=None)

Allow loading of JSON rule data.

oslo_policy.opts

oslo_policy.opts.list_opts()

Return a list of oslo.config options available in the library.

The returned list includes all oslo.config options which may be registered at runtime by the library. Each element of the list is a tuple. The first element is the name of the group under which the list of elements in the second element will be registered. A group name of None corresponds to the [DEFAULT] group in config files. This function is also discoverable via the ‘oslo_messaging’ entry point under the ‘oslo.config.opts’ namespace. The purpose of this is to allow tools like the Oslo sample config file generator to discover the options exposed to users by this library.

Returns:a list of (group_name, opts) tuples

oslo_policy.opts.set_defaults(conf, policy_file=None)

Set defaults for configuration variables.

Overrides default options values.

Parameters:

• conf (oslo.config.cfg.ConfigOpts) – Configuration object, managed by the caller.
• policy_file (unicode) – The base filename for the JSON file that defines policies.