oslo_policy.policy
Module¶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.
For the <rule> part, see Policy Rule Expressions.
Policy rules can be expressed in one of two forms: a string written in the new policy language or a list of lists. The string format is preferred since it’s easier for most people to understand.
In the policy language, each check is specified as 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 |
|
Literals |
|
¹URL checking must return True
to be valid
²User attributes (obtained through the token): user_id, domain_id or project_id
Conjunction operators and
and or
are available, allowing for more
expressiveness in crafting policies. For example:
"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"
Operator precedence is below:
PRECEDENCE | TYPE | EXPRESSION |
---|---|---|
4 | Grouping | (…) |
3 | Logical NOT | not … |
2 | Logical AND | … and … |
1 | Logical OR | … or … |
Operator with larger precedence number precedes others with smaller numbers.
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"]]
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.
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:
Note
Some resources which are exposed by the API do not support policy enforcement by user_id, and only support policy enforcement by project_id. Some global resources do not support policy enforcement by combination of user_id and project_id.
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 allow for more flexibility than is possible using generic
checks. The built-in special check types are role
, rule
, and http
checks.
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>"
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 readability 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"
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"
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.
oslo_policy.policy.
AndCheck
(rules)¶Bases: oslo_policy._checks.BaseCheck
oslo_policy.policy.
Check
(kind, match)¶Bases: oslo_policy._checks.BaseCheck
oslo_policy.policy.
DeprecatedRule
(name, check_str)¶Bases: object
Represents a Deprecated policy or rule.
Here’s how you can use it to change a policy’s default role or rule. Assume the following policy exists in code:
from oslo_policy import policy
policy.DocumentedRuleDefault(
name='foo:create_bar',
check_str='role:fizz',
description='Create a bar.',
operations=[{'path': '/v1/bars', 'method': 'POST'}]
)
The next snippet will maintain the deprecated option, but allow
foo:create_bar
to default to role:bang
instead of role:fizz
:
deprecated_rule = policy.DeprecatedRule(
name='foo:create_bar',
check_str='role:fizz'
)
policy.DocumentedRuleDefault(
name='foo:create_bar',
check_str='role:bang',
description='Create a bar.',
operations=[{'path': '/v1/bars', 'method': 'POST'}],
deprecated_rule=deprecated_rule,
deprecated_reason='role:bang is a better default',
deprecated_since='N'
)
DeprecatedRule can be used to change the policy name itself. Assume the following policy exists in code:
from oslo_policy import policy
policy.DocumentedRuleDefault(
name='foo:post_bar',
check_str='role:fizz',
description='Create a bar.',
operations=[{'path': '/v1/bars', 'method': 'POST'}]
)
For the sake of consistency, let’s say we want to replace foo:post_bar
with foo:create_bar
, but keep the same check_str
as the default. We
can accomplish this by doing:
deprecated_rule = policy.DeprecatedRule(
name='foo:post_bar',
check_str='role:fizz'
)
policy.DocumentedRuleDefault(
name='foo:create_bar',
check_str='role:fizz',
description='Create a bar.',
operations=[{'path': '/v1/bars', 'method': 'POST'}],
deprecated_rule=deprecated_rule,
deprecated_reason='foo:create_bar is more consistent',
deprecated_since='N'
)
Finally, let’s use DeprecatedRule to break a policy into more granular policies. Let’s assume the following policy exists in code:
policy.DocumentedRuleDefault(
name='foo:bar',
check_str='role:bazz',
description='Create, read, update, or delete a bar.',
operations=[
{
'path': '/v1/bars',
'method': 'POST'
},
{
'path': '/v1/bars',
'method': 'GET'
},
{
'path': '/v1/bars/{bar_id}',
'method': 'GET'
},
{
'path': '/v1/bars/{bar_id}',
'method': 'PATCH'
},
{
'path': '/v1/bars/{bar_id}',
'method': 'DELETE'
}
]
)
Here we can see the same policy is used to protect multiple operations on bars. This prevents operators from being able to assign different roles to different actions that can be taken on bar. For example, what if an operator wanted to require a less restrictive role or rule to list bars but a more restrictive rule to delete them? The following will introduce a policy that helps achieve that and deprecate the original, overly-broad policy:
deprecated_rule = policy.DeprecatedRule(
name='foo:bar',
check_str='role:bazz'
)
policy.DocumentedRuleDefault(
name='foo:create_bar',
check_str='role:bang',
description='Create a bar.',
operations=[{'path': '/v1/bars', 'method': 'POST'}],
deprecated_rule=deprecated_rule,
deprecated_reason='foo:create_bar is more granular than foo:bar',
deprecated_since='N'
)
policy.DocumentedRuleDefault(
name='foo:list_bars',
check_str='role:bazz',
description='List bars.',
operations=[{'path': '/v1/bars', 'method': 'GET'}],
deprecated_rule=deprecated_rule,
deprecated_reason='foo:list_bars is more granular than foo:bar',
deprecated_since='N'
)
policy.DocumentedRuleDefault(
name='foo:get_bar',
check_str='role:bazz',
description='Get a bar.',
operations=[{'path': '/v1/bars/{bar_id}', 'method': 'GET'}],
deprecated_rule=deprecated_rule,
deprecated_reason='foo:get_bar is more granular than foo:bar',
deprecated_since='N'
)
policy.DocumentedRuleDefault(
name='foo:update_bar',
check_str='role:bang',
description='Update a bar.',
operations=[{'path': '/v1/bars/{bar_id}', 'method': 'PATCH'}],
deprecated_rule=deprecated_rule,
deprecated_reason='foo:update_bar is more granular than foo:bar',
deprecated_since='N'
)
policy.DocumentedRuleDefault(
name='foo:delete_bar',
check_str='role:bang',
description='Delete a bar.',
operations=[{'path': '/v1/bars/{bar_id}', 'method': 'DELETE'}],
deprecated_rule=deprecated_rule,
deprecated_reason='foo:delete_bar is more granular than foo:bar',
deprecated_since='N'
)
oslo_policy.policy.
DocumentedRuleDefault
(name, check_str, description, operations, deprecated_rule=None, deprecated_for_removal=False, deprecated_reason=None, deprecated_since=None, scope_types=None)¶Bases: oslo_policy.policy.RuleDefault
A class for holding policy-in-code policy objects definitions
This class provides the same functionality as the RuleDefault class, but it also requires additional data about the policy rule being registered. This is necessary so that proper documentation can be rendered based on the attributes of this class. Eventually, all usage of RuleDefault should be converted to use DocumentedRuleDefault.
Parameters: | operations – List of dicts containing each api url and corresponding http request method. Example: operations=[{'path': '/foo', 'method': 'GET'},
{'path': '/some', 'method': 'POST'}]
|
---|
description
¶operations
¶oslo_policy.policy.
DuplicatePolicyError
(name)¶Bases: Exception
oslo_policy.policy.
Enforcer
(conf, policy_file=None, rules=None, default_rule=None, use_conf=True, overwrite=True)¶Bases: object
Responsible for loading and enforcing rules.
Parameters: |
|
---|
A wrapper around ‘enforce’ that checks for policy registration.
To ensure that a policy being checked has been registered this method should be used rather than enforce. By doing so a project can be sure that all of it’s used policies are registered and therefore available for sample file generation.
The parameters match the enforce method and a description of them can be found there.
check_rules
(raise_on_violation=False)¶Look for rule definitions that are obviously incorrect.
clear
()¶Clears Enforcer
contents.
This will clear this instances rules, policy’s cache, file 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: |
|
---|---|
Returns: |
|
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. |
---|
register_default
(default)¶Registers a RuleDefault.
Adds a RuleDefault to the list of registered rules. Rules must be registered before using the Enforcer.authorize method.
Parameters: | default – A RuleDefault object to register. |
---|
register_defaults
(defaults)¶Registers a list of RuleDefaults.
Adds each RuleDefault to the list of registered rules. Rules must be registered before using the Enforcer.authorize method.
Parameters: | default – A list of RuleDefault objects to register. |
---|
oslo_policy.policy.
InvalidContextObject
(error)¶Bases: Exception
oslo_policy.policy.
InvalidDefinitionError
(names)¶Bases: Exception
oslo_policy.policy.
InvalidRuleDefault
(error)¶Bases: Exception
oslo_policy.policy.
InvalidScope
(rule, operation_scopes, token_scope)¶Bases: Exception
Raised when the scope of the request mismatches the policy scope.
oslo_policy.policy.
NotCheck
(rule)¶Bases: oslo_policy._checks.BaseCheck
oslo_policy.policy.
OrCheck
(rules)¶Bases: oslo_policy._checks.BaseCheck
add_check
(rule)¶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.
oslo_policy.policy.
PolicyNotAuthorized
(rule, target, creds)¶Bases: Exception
Default exception raised for policy enforcement failure.
oslo_policy.policy.
PolicyNotRegistered
(name)¶Bases: Exception
oslo_policy.policy.
RuleCheck
(kind, match)¶Bases: oslo_policy._checks.Check
oslo_policy.policy.
RuleDefault
(name, check_str, description=None, deprecated_rule=None, deprecated_for_removal=False, deprecated_reason=None, deprecated_since=None, scope_types=None)¶Bases: object
A class for holding policy definitions.
It is required to supply a name and value at creation time. It is encouraged to also supply a description to assist operators.
Parameters: |
|
---|
oslo_policy.policy.
Rules
(rules=None, default_rule=None)¶Bases: dict
A store for rules. Handles the default_rule setting directly.
from_dict
(rules_dict, default_rule=None)¶Allow loading of rule data from a dictionary.
load
(data, default_rule=None)¶Allow loading of YAML/JSON rule data.
New in version 1.5.0.
oslo_policy.policy.
parse_file_contents
(data)¶Parse the raw contents of a policy file.
Parses the contents of a policy file which currently can be in either yaml or json format. Both can be parsed as yaml.
Parameters: | data – A string containing the contents of a policy file. |
---|---|
Returns: | A dict of the form {‘policy_name1’: ‘policy1’, ‘policy_name2’: ‘policy2,…} |
oslo_policy.policy.
register
(name, func=None)¶Register a function or Check
class as a policy check.
Parameters: |
|
---|
Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.