Policy Authority Module¶
Overview¶
This module is only called for calculating the “Expected” result if
[patrole] test_custom_requirements is False.
Using the PolicyAuthority
class, policy verification is performed by:
Pooling together the default in-code policy rules.
Overriding the defaults with custom policy rules located in a policy.json, if the policy file exists and the custom policy definition is explicitly defined therein.
Confirming that the policy action – for example, “list_users” – exists. (
oslo.policyotherwise claims that role “foo” is allowed to perform policy action “bar”, for example, because it defers to the “default” policy rule and oftentimes the default can be “anyone allowed”).Performing a call with all necessary data to
oslo.policyand returning the expected result back torbac_rule_validationdecorator.
When to use¶
This RbacAuthority class
can be used to validate the default OpenStack policy configuration. It
is recommended that this approach be used for RBAC validation for clouds that
use little to no policy customizations or overrides.
This validation approach should be used when:
Validating the out-of-the-box policy-in-code OpenStack policy configuration.
It is important that the default OpenStack policy configuration be validated before deploying OpenStack into production. Bugs exist in software and the earlier they can be caught and prevented (via CI/CD, for example), the better. Patrole continues to be used to identify default policy bugs across OpenStack services.
Validating policy reliably and accurately.
Relying on
oslo.policyto compute the expected test results provides accurate tests, without the hassle of having to reinvent the wheel. Since OpenStack APIs useoslo.policyfor policy enforcement, it makes sense to compute expected results by using the same library, ensuring test reliability.Continuously validating policy changes to OpenStack projects under development by gating them against Patrole CI/CD jobs run by Zuul.