Approval policies are a level of governance that you add to exercise control over deployment and day 2 action requests before they are run. You define approval policies in Service Broker so that you, or others that you designate, review requests before resources are consumed or destroyed. The approval policy use cases in this procedure are an introduction that you can use as you explore your governance options.

If you have only a small team adding and deploying catalog items, then approval policies might be less useful. But as you make the catalog available to a larger group of developers and general consumers, you can use the approval policies to ensure that someone reviews a request before the resources are consumed or changes are made to the provisioned items.

For example, you have a catalog item that is important, but it consumes a significant amount of resources. You want one of your IT administrators to review any deployment requests to ensure that the request is needed. Another example applies to day 2 actions. Making changes to a deployment that is used by many might be devastating. You want the project administrator who manages the deployment for that team to review all changes to the deployed catalog item.

Who works with or is affected by approval policies?

  • Service Broker administrator. Configures the policies.
  • Catalog consumers. Users who request catalog items or day 2 actions to which one or more policies apply.
  • Users deploying cloud templates in Cloud Assembly. Users who request templates or day 2 actions in Cloud Assembly to which one or more policies apply.
  • Designated approvers. Users who must review and then approve or reject a request. You can grant approver rights to selected users and user groups, or you can choose from the following approver roles.
    • AD Manager. Active Directory user with manager attributes. See Configure Active Directory attributes for the AD Manager approver role
    • Project Administrators. Administrators of projects within the policy scope are automatically assigned as approvers. If a project does not have a dedicated administrator, the approval policy is not applied to that project.
    • Project Supervisors. Members of projects within the policy scope who are assigned the Supervisor role. Supervisor access rights are limited to approving and rejecting deployment requests for a project. If a project does not have a dedicated supervisor, the approval policy is not applied to that project.

What happens when approval policies are enforced?

Multiple approval policies might be enforceable. The approval policies are evaluated, and an enforced policy is applied to the request. When there are multiple valid policies, where the approvers are different people, all the approvers are added. When you have multiple policies, it is important to understand this process. For more information, see Approval policy goals and enforcement examples.

  1. Approval policies are defined.
  2. A user requests a catalog item or day 2 action. At request time, Service Broker evaluates the catalog item to see if any policies apply.
  3. An approval policy is enforced.
    1. The deploy card displays the status. For example, Create - Approval Pending.
    2. An email notification is sent to the requester. See How do I track my requests that require approval.
    3. An email notification is sent to the approvers. See How do I respond to an approval request.

      The deployment does not begin deploying and consuming infrastructure resources, or make changes to a deployed system, until the request is approved. The requesting user is notified by email that the request is waiting for approval.

    4. The approvers respond to the request using the Approvals page in Service Broker.
  4. The approval process is completed.
    1. If the request is rejected, the requesting user is notified and the deployment request is canceled.
    2. If the request is approved, the deployment proceeds.
    3. It is possible that the enforced policy is configured to automatically approve or reject a request if the approver does not take any action.

How can I use the deployment criteria?

To limit what items or activities the policy applies to, you can define the deployment criteria. For more about the criteria, see How do I configure deployment criteria in Service Broker policies.

Approval policy constraints

  • The change lease action is not available to include in an approval policy.
  • Using custom resources as resource type in the policy criteria is not supported.

As you review the approval policies use case and create your own policy, consult the signpost help on the key text boxes for more information.

Prerequisites

  • An approver, who might not be a regular Service Broker or Cloud Assembly user, must have one of the following combination of roles:
    • Organization member and Service Broker user
    • Organization member and the Manage Approvals custom role

    These roles provide the minimum level of permissions and still allow them to approve or reject a request.

  • Verify that the email notification server is defined. See Add an email server in Service Broker to send notifications.
  • If you plan to use the Active Directory manager as the role-based approval type, you must use the Workspace One Access VMware Identity Manager integration configured for vRealize Automation. You must also include the Active Directory manager attributes in the user attributes. See Configure Active Directory attributes for the AD Manager approver role

Procedure

  1. Select Content and Policies > Policies > Definitions > New Policy > Approval Policy.
  2. Configure Approval Policy 1.
    As an administrator, you have an important catalog item that also consumes a significant amount of your cloud resources. You want several managers to review any deployment requests to ensure that the request is really needed and that the resources exist to support it.
    1. Define when the policy is valid.
      Setting Sample Value
      Scope Organization

      This policy is applied to all projects in your organization.

      Criteria 
      Catalog Item equals CompanyApplication
    2. Define the approval behavior.
      Setting Sample Value
      Approval level 1

      You prioritize levels based on the order that you want them processed.
      Approval type Select User based.

      You select the users and user groups who are the request approvers.
      Approver mode All

      You want all your IT managers to agree that the deployment request does not waste resources.
      Approvers {GroupName1}@YourCompany, {ApproverName1}@YourCompany, {ApproverName2}@YourCompany

      The approval request is sent to all members of the user group. Only one member of the group must approve the request.
      Auto expiry decision Reject

      The possible load on your cloud resources means that you do not want to inadvertently deploy the item without approval.
      Auto expiry trigger 3

      This value should carry you over a long weekend when the managers might not be available.
      Actions Deployment.Create
    In this scenario, if any catalog consumer requests this catalog item, Approver 1, Approver 2, and any one member of User Group 1 must approve the request within 3 days or the request is rejected.
  3. Configure Approval Policy 2.
    As an administrator, you have several projects where you want the project administrators to approve any changes to deployments that might have catastrophic consequences. For example, deleting the deployment.
    1. Define when the approval policy is valid.
      Setting Sample Value
      Scope
      Multiple Projects 
      Project name contains Prod

      The policy is applied to deployments associated with all projects that match the scope criteria.
      Criteria None
    2. Define the approval behavior.
      Setting Sample Value
      Approval level 1
      Approval type Select Role based.
      Approver role Project Administrators

      If a project does not have a dedicated administrator, the approval policy is not applied to requests associated with that project.

      Approver mode Any
      Auto expiry decision Reject
      Auto expiry trigger 7
      Actions Deployment.Delete, Deployment.PowerOff, Deployment.Update, and any of the component-specific power, reboot, and delete actions.
    In this scenario, when a member of one of the scoped projects submits a request to run the listed actions on a deployment, the request is rejected after seven days if the project administrator does not respond.
  4. Configure Approval Policy 3.
    As an administrator, you want to maintain a little control over resource consumption. For example, when a user requests a catalog item where the size is large, you want to evaluate and approve the request. Size is defined by the flavor mappings.
    1. Define when the approval policy is valid.
      Setting Sample Value
      Scope Organization
      Criteria 
      Resources has any 
     Flavor equals large
    2. Define the approval behavior.
      Setting Sample Value
      Approval level 1
      Approval type Select User based.
      Approver mode Any
      Approvers {AdminName}@YourCompany
      Auto expiry decision Reject

      The possible consumption of your cloud resources means that you do not want to inadvertently deploy the item without approval.
      Auto expiry trigger 5
      Actions Deployment.Create and any applicable *.Machine.Resize actions. For example, Cloud.vSphere.Machine.Resize.
      In this scenario, when any user submits a request for a large deployment or to resize a deployment to large, the request is rejected after 5 days if the cloud administrator does not respond.

What to do next