| [DEFAULT] |
| |
| |
| [patrole] |
| |
| # |
| # From patrole.config |
| # |
| |
| # DEPRECATED: The current RBAC role against which to run |
| # Patrole tests. (string value) |
| # This option is deprecated for removal. |
| # Its value may be silently ignored in the future. |
| # Reason: This option is deprecated and being |
| # replaced with ``rbac_test_roles``. |
| #rbac_test_role = |
| |
| # The current RBAC roles to be assigned to Keystone |
| # Group against which to run Patrole tests. (list value) |
| #rbac_test_roles = admin |
| |
| # List of the paths to search for policy files. Each |
| # policy path assumes that the service name is included in the path |
| # once. Also |
| # assumes Patrole is on the same host as the policy files. The paths |
| # should be |
| # ordered by precedence, with high-priority paths before low-priority |
| # paths. All |
| # the paths that are found to contain the service's policy file will |
| # be used and |
| # all policy files will be merged. Allowed ``json`` or ``yaml`` |
| # formats. |
| # (list value) |
| #custom_policy_files = /etc/%s/policy.json |
| |
| # |
| # This option determines whether Patrole should run against a |
| # ``custom_requirements_file`` which defines RBAC requirements. The |
| # purpose of setting this flag to ``True`` is to verify that RBAC |
| # policy |
| # is in accordance to requirements. The idea is that the |
| # ``custom_requirements_file`` precisely defines what the RBAC |
| # requirements are. |
| # |
| # Here are the possible outcomes when running the Patrole tests |
| # against |
| # a ``custom_requirements_file``: |
| # |
| # YAML definition: allowed |
| # test run: allowed |
| # test result: pass |
| # |
| # YAML definition: allowed |
| # test run: not allowed |
| # test result: fail (under-permission) |
| # |
| # YAML definition: not allowed |
| # test run: allowed |
| # test result: fail (over-permission) |
| # (boolean value) |
| #test_custom_requirements = false |
| |
| # |
| # File path of the YAML file that defines your RBAC requirements. This |
| # file must be located on the same host that Patrole runs on. The YAML |
| # file should be written as follows: |
| # |
| # .. code-block:: yaml |
| # |
| # <service_foo>: |
| # <api_action_a>: |
| # - <allowed_role_1> |
| # - <allowed_role_2> |
| # - <allowed_role_3> |
| # <api_action_b>: |
| # - <allowed_role_2> |
| # - <allowed_role_4> |
| # <service_bar>: |
| # <api_action_c>: |
| # - <allowed_role_3> |
| # |
| # Where: |
| # |
| # service = the service that is being tested (cinder, nova, etc.). |
| # |
| # api_action = the policy action that is being tested. Examples: |
| # |
| # * volume:create |
| # * os_compute_api:servers:start |
| # * add_image |
| # |
| # allowed_role = the ``oslo.policy`` role that is allowed to perform |
| # the API. |
| # (string value) |
| #custom_requirements_file = <None> |
| |
| |
| [patrole_log] |
| |
| # |
| # From patrole.config |
| # |
| |
| # Enables reporting on RBAC expected and actual test results for each |
| # Patrole test (boolean value) |
| #enable_reporting = false |
| |
| # Name of file where output from 'enable_reporting' is logged. Note |
| # that this file is recreated on each invocation of patrole (string |
| # value) |
| #report_log_name = patrole.log |
| |
| # Path (relative or absolute) where the output from 'enable_reporting' |
| # is logged. This is combined withreport_log_name to generate the full |
| # path. (string value) |
| #report_log_path = . |
| |
| |
| [policy-feature-enabled] |
| |
| # |
| # From patrole.config |
| # |
| |
| # Is the Neutron policy |
| # "create_port:fixed_ips:ip_address" available in the cloud? This |
| # policy was |
| # changed in a backwards-incompatible way. (boolean value) |
| #create_port_fixed_ips_ip_address_policy = true |
| |
| # Is the Neutron policy |
| # "update_port:fixed_ips:ip_address" available in the cloud? This |
| # policy was |
| # changed in a backwards-incompatible way. (boolean value) |
| #update_port_fixed_ips_ip_address_policy = true |
| |
| # Is the Cinder policy |
| # "limits_extension:used_limits" available in the cloud? This policy |
| # was |
| # changed in a backwards-incompatible way. (boolean value) |
| #limits_extension_used_limits_policy = true |
| |
| # Is the Cinder policy |
| # "volume_extension:volume_actions:attach" available in the cloud? |
| # This policy |
| # was changed in a backwards-incompatible way. (boolean value) |
| #volume_extension_volume_actions_attach_policy = true |
| |
| # Is the Cinder policy |
| # "volume_extension:volume_actions:reserve" available in the cloud? |
| # This policy |
| # was changed in a backwards-incompatible way. (boolean value) |
| #volume_extension_volume_actions_reserve_policy = true |
| |
| # Is the Cinder policy |
| # "volume_extension:volume_actions:unreserve" available in the cloud? |
| # This policy |
| # was changed in a backwards-incompatible way. (boolean value) |
| #volume_extension_volume_actions_unreserve_policy = true |
| |
| # Are the Nova API extension policies available in the |
| # cloud (e.g. os_compute_api:os-extended-availability-zone)? These |
| # policies were |
| # removed in Stein because Nova API extension concept was removed in |
| # Pike. (boolean value) |
| #removed_nova_policies_stein = true |
| |
| # Are the Cinder API extension policies available in the |
| # cloud (e.g. [create|update|get|delete]_encryption_policy)? These |
| # policies are |
| # added in Stein. (boolean value) |
| #added_cinder_policies_stein = true |