Policy governance for Cloud Management

Policies give you a detailed level of control over approvals, resource operations, blueprint operations, and catalog items.

Use policies to do things like override values, run workflows, execute a custom script, or abort a workflow.
Note: Multiple policies running simultaneously might slow down your system. Keep policies active only when you require them to run and deactivate any unnecessary policies.

Policy components

Policies are comprised of these components:
Policy component Description
Operations The operation that is run on a catalog item or stack.
Triggers The time the policy is put into affect. Triggers are based on the operations that can be run on a resource item or a stack, as the time a catalog item is provisioned to a user. Triggers can also be based on approval workflows, such as the approval workflow that is kicked off when a catalog item is requested.
Groups The group that the policy belongs to. Group similar policies together.
Conditions Optional restrictions that determine if actions are fired. Conditions can be based on form data from a catalog item or on user data.
Actions The actions that the policy can take when the policy is triggered and the condition, if present, is met. A set of action types are available by default. As an example, you can override properties in a catalog item when a user configures a form for the requested item.
Note: You can override properties in policy actions and blueprint form event actions. If you configure overrides in both places, the blueprint form event override gets triggered last and takes precedence.
Rules A container for a set of optional conditions and actions that are run when the conditions are met.
Note: You cannot edit policy rules, conditions, and actions when policy is in the published state.

Policy operation examples

Policies are based on the operations that can be performed on catalog items and stacks, where the operations are defined in the blueprint that the catalog item or stack is based on. These are example operations:
Operation Description
All Any operation applies.
Start The resource is started.
Stop The resource is stopped.
Provision The resource is provisioned to a user.
Deprovision The resource is no longer available to users.
Execute Script A script is run on the resource.

Policy triggers

Policies take affect when certain actions or events, called triggers, take place. These triggers are available by default:

Trigger Description
on Blueprint provision When a catalog item is provisioned to a user. use this trigger to override a value that user inputs. For example, when a user chooses a value for an attribute like the stack name, a policy with this trigger can change the stack name to something else that you specify when the user finally provisions the resource. The user does not see the final value on the catalog item form because the change is made at provision.
on Blueprint provision approval When a catalog item request needs to be approved. Use this trigger to specify a specific approval workflow that you want.
on Catalog item launch When a user opens a catalog item. When the form for the item loads, this trigger takes place. Use this trigger to override a default value that appears to the user when the form loads. The user can see this value on the catalog item form.
on Catalog item request start When a user starts to request a catalog item. Use this trigger to launch a workflow before the catalog item request is processed.
on Catalog item request end After a user finishes selecting the catalog item options and wants to provision the request. Use this trigger to launch a workflow after the catalog item request is processed. Consider this a post-provisioning step. For example, you could launch a workflow to install MySQL on the provisioned resource.
on Resource operation When an operation, such as start or stop, is performed on a specific resource.
on Stack operation approval When an approval is required for an operation on a stack of cloud resources. Use this trigger to specify an approval workflow when an operation is performed on a stack. By default, a change request is generated when an operation is performed on a stack, but it does not require an approval. This trigger can launch a mandatory approval.
on Stack resource operation approval When an approval is required for an operation on a single resource that is part of a stack.

Policy execution order

Each policy has an Order of Execution field that determines when the policy is run in relation to other policies. Rules and actions also have an Order field to determine when they apply in relation to other rules and actions respectively. The policy with the lowest order number is run first.

However, that does not mean that the actions for the lowest-order policy is actually taken. For policies that do not deal with approvals, the most specific policy always wins. This means that policies that have specific resource blocks, operations, or other details configured are applied instead of more generic policies that are missing those non-mandatory field values.