Policies

Warning

JSON formatted policy file is deprecated since Watcher 6.0.0 (Wallaby). This oslopolicy-convert-json-to-yaml tool will migrate your existing JSON-formatted policy file to YAML in a backward-compatible way.

Watcher’s public API calls may be restricted to certain sets of users using a policy configuration file. This document explains exactly how policies are configured and what they apply to.

A policy is composed of a set of rules that are used in determining if a particular action may be performed by the authorized tenant.

Constructing a Policy Configuration File

A policy configuration file is a simply JSON object that contain sets of rules. Each top-level key is the name of a rule. Each rule is a string that describes an action that may be performed in the Watcher API.

The actions that may have a rule enforced on them are:

• strategy:get_all, strategy:detail - List available strategies

  • GET /v1/strategies

  • GET /v1/strategies/detail

• strategy:get - Retrieve a specific strategy entity

  • GET /v1/strategies/<STRATEGY_UUID>

  • GET /v1/strategies/<STRATEGY_NAME>

• goal:get_all, goal:detail - List available goals

  • GET /v1/goals

  • GET /v1/goals/detail

• goal:get - Retrieve a specific goal entity

  • GET /v1/goals/<GOAL_UUID>

  • GET /v1/goals/<GOAL_NAME>

• audit_template:get_all, audit_template:detail - List available audit_templates

  • GET /v1/audit_templates

  • GET /v1/audit_templates/detail

• audit_template:get - Retrieve a specific audit template entity

  • GET /v1/audit_templates/<AUDIT_TEMPLATE_UUID>

  • GET /v1/audit_templates/<AUDIT_TEMPLATE_NAME>

• audit_template:create - Create an audit template entity

  • POST /v1/audit_templates

• audit_template:delete - Delete an audit template entity

  • DELETE /v1/audit_templates/<AUDIT_TEMPLATE_UUID>

  • DELETE /v1/audit_templates/<AUDIT_TEMPLATE_NAME>

• audit_template:update - Update an audit template entity

  • PATCH /v1/audit_templates/<AUDIT_TEMPLATE_UUID>

  • PATCH /v1/audit_templates/<AUDIT_TEMPLATE_NAME>

• audit:get_all, audit:detail - List available audits

  • GET /v1/audits

  • GET /v1/audits/detail

• audit:get - Retrieve a specific audit entity

  • GET /v1/audits/<AUDIT_UUID>

• audit:create - Create an audit entity

  • POST /v1/audits

• audit:delete - Delete an audit entity

  • DELETE /v1/audits/<AUDIT_UUID>

• audit:update - Update an audit entity

  • PATCH /v1/audits/<AUDIT_UUID>

• action_plan:get_all, action_plan:detail - List available action plans

  • GET /v1/action_plans

  • GET /v1/action_plans/detail

• action_plan:get - Retrieve a specific action plan entity

  • GET /v1/action_plans/<ACTION_PLAN_UUID>

• action_plan:delete - Delete an action plan entity

  • DELETE /v1/action_plans/<ACTION_PLAN_UUID>

• action_plan:update - Update an action plan entity

  • PATCH /v1/audits/<ACTION_PLAN_UUID>

• action:get_all, action:detail - List available action

  • GET /v1/actions

  • GET /v1/actions/detail

• action:get - Retrieve a specific action plan entity

  • GET /v1/actions/<ACTION_UUID>

• service:get_all, service:detail - List available Watcher services

  • GET /v1/services

  • GET /v1/services/detail

• service:get - Retrieve a specific Watcher service entity

  • GET /v1/services/<SERVICE_ID>

To limit an action to a particular role or roles, you list the roles like so

{
  "audit:create": ["role:admin", "role:superuser"]
}

The above would add a rule that only allowed users that had roles of either “admin” or “superuser” to launch an audit.