Cloud Configuration Governance

During initial installation, you set up one cloud account. To organize and compartmentalize your infrastructure, you can set up additional cloud accounts to include different providers or service accounts or datacenters.

When you add credentials to an image template, the credentials are inherited by all VMs that are provisioned using the template.

At any time, you can add a logical datacenter to the cloud infrastructure that is represented by a cloud account.

You can add fields to a cloud catalog form if you want the user to enter additional information beyond what a default blueprint provides.

After you configure operations and input parameters for your resource block, add steps for each operation to tell the system which Cloud API (CAPI) to call. Each step is a separate call to CAPI.

Create a post-provisioning operation using subflows on a template-based catalog item.

You can make any AWS image selectable in an OS profile.

You can make any Azure image selectable in an OS profile.

Invoke a subflow by adding an operation step to a resource and linking it to a new or existing subflow.

The base system includes a large set of predefined resource operations. Rarely, you might add a custom operation for a resource.

A resource script operates on a resource during deployment or returns data to the CMDB after a resource is deployed.

Your instance tracks tagged resources for billing and reporting. Policy action scripts can add and modify resource tags. This example tags a storage volume resource.

After you have activated the Terraform store app for Cloud Provisioning and Governance, to support cloud-based operations for cloud providers using Terraform Open Source Edition. Add the Terraform Orchestration interface on resource block, to execute cloud-based operations via terraform templates.

This example walks you through an existing set of blueprint rules that Cloud Provisioning and Governance provides by default.

Associate the Terraform environment variable with the Cloud Provisioning and Governance datacenter resource block. After associating the environment variable, you can use it to pass custom inputs parameters during resource deployment through Terraform Enterprise.

During Cloud Provisioning and Governance Day 1 setup, you added one service account to the cloud account. To compartmentalize your infrastructure or to include different datacenters, you can add another service account. A particular datacenter, however, cannot be selected in more than one service account in a cloud account.

You assign Cloud Provisioning and Governance roles to user groups and to individual users based on user activities and responsibilities.

Define the scheduled job that regularly uses a MID Server to download billing data from the provider. Cloud Provisioning and Governance saves the data in a cost table and uses the information to generate reports.

A single set of cloud billing data can be large. The MID Server, therefore, sends the data to the ECC queue in manageable chunks. You can optionally configure a system property to limit the size of each chunk to avoid performance issues caused by large data transfers.

The Discovery process discovers AWS services.

Reference code sample to deploy an Amazon AWS Cloud EC2 instance.

A service account is a secure record on your instance that stores the credential and access information for your provider account. Discovery uses the information to access your provider account to get data on each resource in each specified datacenter. A cloud account is the logical representation in Cloud Provisioning and Governance of all or part of your managed cloud infrastructure. A cloud account can include multiple service accounts — even service accounts from different providers. For each service account, you specify which datacenters to include in the cloud account.

Skip this procedure if your organization does not use AWS GovCloud (US). To securely access data on your provider account, the Discovery process must present appropriate credentials. An AWS GovCloud (US) region is an isolated AWS region that meets stringent US government security and compliance requirements to host sensitive workloads. Cloud Provisioning and Governance supports all AWS GovCloud (US) services.

If your organization uses AWS GovCloud (US) region, you must create a service account in the region where you provision the resources. These credentials that you create are used for Cloud Discovery, Cloud Provisioning and Governance, and Cloud Cost Management.

You assign Cloud Provisioning and Governance roles to user groups and to individual users based on user activities and responsibilities.

Define the scheduled job that regularly uses a MID Server to download billing data from the provider. Cloud Provisioning and Governance saves the data in a cost table and uses the information to generate reports.

A single set of cloud billing data can be large. The MID Server, therefore, sends the data to the ECC queue in manageable chunks. You can optionally configure a system property to limit the size of each chunk to avoid performance issues caused by large data transfers.

A cloud account is the logical representation in Cloud Provisioning and Governance of all or part of your managed cloud infrastructure. A cloud account can include multiple service accounts — even service accounts from different providers. For each service account, you specify which datacenters to include in the cloud account.

To securely access data on your provider account, the Discovery process must present appropriate credentials. To make the credentials available to Discovery, you first create Azure service principal credentials in the Azure Portal. You then securely store the credentials in a service account in your instance.

To securely access resource and billing data on your Microsoft Azure account, the Discovery process must present appropriate Microsoft Azure account credentials. You create a special programmatic account — a Microsoft Azure service principal — to generate the required credentials.

The Discovery process discovers Microsoft Azure services.

During Cloud Provisioning Day 1 setup, you added one service account to the cloud account. To compartmentalize your infrastructure or to include different datacenters, you can add another service account. A particular datacenter, however, cannot be selected in more than one service account in a cloud account. Note: Resource ID

To make catalog ordering less error-prone, you can bind a parameter to an resource pool (a pool provided in the base system). Parameters that are based on an resource pool list only specified values from existing tables on the catalog order form in the Cloud User Portal.

When you add a blueprint operation to a resource, the system adds the appropriate attributes. You can choose whether or not to make the attributes available as catalog properties on the form when the system performs the operation.

Blueprints control what the user sees on the catalog order form. You can configure the form to show or hide fields, populate fields with default values, and otherwise create a unique form for the user based on criteria.

A blueprint is a specialized catalog item template for offering cloud services, or stacks, to cloud users. Blueprints work with any cloud service provider, such as Amazon AWS Cloud or Microsoft Azure Cloud. Blueprints are in restricted usage from the Orlando release.

You can set up business hour scheduling on all virtual machines in a stack. Business hour scheduling can be set up on stacks at the time of provisioning or on existing stacks.

You can create and publish a catalog item directly from a blueprint.

Create a catalog item from the Terraform template to request cloud resource provisioning. Activated catalog items appear in the cloud user portal.

Cloud Services Catalog Terraform Connector uses the SSH private key credential to connect with the Linux server on which Terraform Open Source is running.

Cloud Services Catalog Terraform Connector uses the Windows credential to connect with the Windows server on which Terraform Open Source is running.

A cloud account is the logical representation in Cloud Provisioning and Governance of all or part of your managed cloud infrastructure. A cloud account can include multiple service accounts — even service accounts from different providers. For each service account, you specify which datacenters to include in the cloud account.

The Cloud Admin Portal is a role-based portal. You can manage, design, govern, operate, and analyze all your cloud resources from a unified base.

The Cloud API Trail is an activity log for all activity that uses the Cloud API and goes through the MID Server.

After you set up the Cloud Provisioning and Governance application on your instance, there are many items that you must configure before your users can request and manage any cloud resources.

Dashboards enable cloud admins and cloud users to view reports like cloud billing data and cloud tag usage.

Governance refers to the limitations that you can set on available cloud resources.

The Cloud API (CAPI) enables you to integrate Cloud Provisioning and Governance with cloud providers using REST APIs.

The ServiceNow Cloud Provisioning and Governance (CPG) application serves as a unified interface for accessing cloud resources, delivering cloud offerings to a catalog, and overseeing resource usage. This application is transformed as Cloud Services Catalog application, offering refined and streamlined management of usage and life cycle of cloud resources.

Review the following considerations to effectively create, implement, and maintain domain separation for Cloud Provisioning and Governance services in the instance that you are setting up for your customers.

Multi-cloud recipes provide ready content for typical cloud deployment and common operations scenarios across cloud platforms.

To set up Cloud Provisioning and Governance for the very first time, you perform the procedures in this "Day 1" setup guide. Be sure to perform the procedures in order. After you have performed Day 1 setup, you can perform optional Day 2 setup and configuration procedures as needed and in any order. Detailed instructions for each procedure follow this overview.

To set up Cloud Provisioning and Governance for the very first time, you perform the procedures in this "Day 1" setup guide. Be sure to perform the procedures in order. After you have performed Day 1 setup, you can perform optional Day 2 setup and configuration procedures as needed and in any order. Detailed instructions for each procedure follow this overview.

To set up Google Cloud for the first time, follow the steps in this Day 1 setup guide in the order they are presented. After completing the Day 1 setup, you can proceed with the optional Day 2 configuration steps as needed, in any order. Detailed instructions for each step are provided in the sections below.

After you have performed Day 1 setup, you can perform optional setup and configuration procedures as needed and in any order. Detailed instructions for each procedure follow this overview.

The tables are cloud-agnostic and can therefore hold data for any cloud provider.

To set up Cloud Provisioning and Governance for the very first time, you perform the procedures in this "Day 1" setup guide. Be sure to perform the procedures in order. After you have performed Day 1 setup, you can perform optional Day 2 setup and configuration procedures as needed and in any order. Detailed instructions for each procedure follow this overview.

The Cloud Orchestration Trail is an activity log for all cloud resource activity on the instance.

Permissions are user group-level access rights to features in the Cloud Provisioning and Governance application and to specific records in the instance, such as blueprints or cloud accounts.

A cloud policy can override a property value set by a user, create an approval task, reserve an IP address, pre-populate or hide form fields, execute custom scripts, call the Cloud API, or start or abort subflows. It gives you system-wide control over approvals, resource operations, blueprint operations, or catalog item settings.

Resource profiles are cloud provider-agnostic definitions that specify the allowed attribute values for a resource. Resource profiles enable you to control the choices that the user sees when requesting a cloud resource. As a result, you do not need to define a unique blueprint for each variation of the resource.

In the Cloud Provisioning and Governance application, script execution is divided into cloud scripts and cloud script templates. Use scripts in blueprints, resource blocks, OS profiles, and use policy scripts to set request form attributes. Policy scripts cannot override user data.

Tags categorize cloud resources to provide richer and more detailed tracking and billing report data.

When a stack reaches the end of its lease, the system notifies the stack owner and deprovisions the stack. You can modify the lease for a stack before it approaches its end date.

Business hours scheduling can be performed on stacks at the time of provisioning or on existing stacks.

The Cloud User Portal gives you immediate access to all day-to-day cloud activities.

A stack might include a virtual machine that requires an SSH key for access. To request such a stack, you can either use a key pair that is assigned to you or you can generate another key.

If a resource on a stack requires login, then you must download the associated SSH key before you can access the resource.

Launch a stack of cloud resources to submit a request for an item in the service catalog. You can launch a stack from the Cloud User Portal overview page.

Operations like Start/Stop, Deprovision, and ExecuteScript are called life-cycle operations or day-2 operations. When you request a life-cycle operation on a stack or resource, the system generates a change request. An approval policy specifies either that the change is auto-approved or that a user on the approver list must approve the change.

Use the Resource Details page to view details and status for a resource and to perform life cycle operations on a resource.

Use the Stack Details page to view details and status for a stack and to perform life-cycle operations on a stack.

The Search page returns search results and provides filters that help you to zoom in on the results.

Submit an incident for a stack when it is not working as expected or you have questions. When the user responds or solves the issue, the incident is closed.

The system generates a change request when you perform a life cycle operation on a stack or resource.

Before an incident is resolved and closed, you can view the state of the incident.

The system generates a request when you submit the form to launch a stack.

Use the Activities page to view and manage details of your cloud actions.

You can view the events that are generated from your cloud resources if your administrator configured Cloud Provisioning and Governance to monitor them. All events are listed on the Cloud Events tab on the stack details page.

Configure a rule that contains actions the system can take on blueprint attributes.

Configure Ansible Tower credentials to access the Ansible Automation Engine through your instance.

A policy rule is a collection of conditions and actions. ​If all conditions evaluate to true, the policy engine performs the actions. If any condition evaluates to false, the policy engine does not perform the actions.

Understand the high-level workflow for configuring the Cloud Services Catalog Terraform Connector application.

Customize the AWS roles that a MID Server can assume to receive temporary credentials for member accounts. You can configure additional parameters to improve security and customize the way that the member account’s role is assumed when discovering cloud resources.

You can configure endpoint mapping on a storage volume to make a connection to a resource.

Configure a response processor to handle responses from datacenters.

Reduce the number of steps required to create and manage multiple catalog items and order guides by creating variable sets. With variable sets, you don't have to create variables individually for each catalog item.

Through blueprints, you can control how form fields appear to users in the cloud catalog. For example, you can control where the fields appear to users on the catalog item form, and whether they are read only or mandatory.

The Cloud Services Catalog Terraform Connector uses API key credentials to authenticate the requests sent to the Terraform Enterprise and Terraform Cloud and the version control systems provisioned in them.

Use the Terraform Catalog Item Task form to specify the action you want to take to resolve the catalog item change task.

Cloud Provisioning and Governance uses the config provider to interact with the Terraform deployment.

Use the ServiceNow Cloud Services Catalog Terraform Connector to generate catalog items from the Terraform templates and use them to provision and manage resources in various clouds.

Reference topics provide additional information about the Cloud Services Catalog Terraform Connector application.

If the base system does not provide a CI type for cloud-based virtual resources, you can create a CI class based on the virtual machine object class.

A policy that is triggered by one of the approval triggers can start approval subflows. The approval triggers are ( on Blueprint provision (approval), on Stack operation (approval), on Stack resource operation (approval), and on Task remediation .

The on Blueprint provision trigger fires after execution of on Catalog item request start policies. A policy that is triggered by the on Blueprint provision trigger can run a script, override a user-requested attribute value, or abort and send a message about the provision operation.

The on Catalog item launch trigger fires when an order form (stack request form) is launched for a catalog item. A policy that is triggered by the on Catalog item launch trigger can run a script or override a user-requested value (text values only).

The on Catalog item request start trigger fires after the user opens a request form. The on Catalog item request end trigger fires after a user submits a request form. A policy that is triggered by the on Catalog item request start or on Catalog item request end trigger can run a script or execute a subflow.

A policy that is triggered by the on Lease end trigger can send a notification or perform a Start, Stop, or Deprovision life cycle operation.

The on Task remediation trigger fires when a user resubmits a failed request. A policy that is triggered by the on Task Remediation trigger can start approval subflows.

Set the on Resource limits exceeded policy to automatically run approval subflows or send notifications when a template-based catalog item order exceeds defined resource limits.

The on Resource operation trigger fires during the Orchestration process when a user performs a Start, Stop, or Deprovision life cycle operation on a specific resource. A policy that is triggered by the on Resource operation trigger can override a user-requested attribute value, run a script, call a Cloud API, or perform an IP address management operation.

The on Resource operation launch trigger fires before the catalog for a resource operation is loaded from the Cloud User Portal. A policy that is triggered by the on Resource operation launch trigger can run a script or can override a user-requested value (text values only).

A policy that is triggered by the on Resource operation request start or on Resource operation request end trigger can run a script or override a user-requested attribute value.

If the existing CAPI APIs do not integrate with the CAPI interface for a provider, you can create an API. The steps in resource blocks can call your API methods when operations are executed.

An application profile specifies application software to install on newly-provisioned resources. Users can select applications when they request a stack. Use application profiles when you integrate with configuration management (continuous delivery) providers such as Ansible playbooks.

Use the blueprint designer to create custom blueprints for the Cloud Provisioning and Governance application. Blueprints are deprecated in the Orlando release.

Create an Ansible configuration management provider, and then run Discovery on the provider to find its resources.

A cloud approval policy specifies the users who must approve a specified cloud activity before the activity can proceed. Approvers can include the manager of the user making a request, a specified user or group, or users with a specified role. You can specify multiple approvers. Approvals occur in the order that you specify.

Create a cloud catalog item for provisioning, based on a template or an existing blueprint, and publish the catalog item to provide a service.

This example shows a cloud script that runs after a user provisions a virtual machine.

Create cloud initialization templates and a script to use during VM provisioning.

A cloud policy group is a container for related policies. Consider grouping policies that are often used together or should be considered together. Grouping policies can help you to apply policies consistently across your organization.

A cloud policy can override a property value set by a user, create an approval task, reserve an IP address, pre-populate or hide form fields, execute custom scripts, call the Cloud API, or start or abort subflows. It gives you system-wide control over approvals, resource operations, blueprint operations, or catalog item settings.

Based on blueprint settings, resource pools control the values that a user sees in a catalog item when they request a resource. Only values that pass the pool filter or script appear as options on the catalog item request form.

A cloud quota definition specifies the limitations on a resource block. You can use templates or manually create different types of configurations for each quota definition.

Create a cloud template and associate the template with a catalog item. Once you've created a template, you can reuse the template to create additional catalog items for the services you want to provision.

A compute profile specifies the hardware to use for newly-provisioned virtual machines. A compute profile maps to a cloud account, a datacenter, and a hardware template.

A compute security group profile applies specified security rules to newly-provisioned resources. You map a compute security group profile to a cloud account, a datacenter, a Compute Security Group template, and security rules for the template.

To integrate with Infoblox, you must create an Infoblox record and associate it with the appropriate credentials to register your Infoblox server with the instance.

You can create a new CAPI interface or extend an existing one by adding new operations.

Create an IP pool to associate a cloud subnet with an IPAM provider instance.

Use an Infrastructure as Code (IaC) change task to create or update the Terraform template-based catalog items. The IaC change task helps ensure that the catalog items are aligned with the latest infrastructure specifications coded in the Terraform template.

An OS profile installs a specified image on a newly-provisioned virtual machine. You map an OS profile to a cloud account, a location (datacenter), an image template, and a cloud script. OS profiles are provider-agnostic and you can use the same profile for multiple cloud accounts.

Assign a permission to refine the actions that are allowed or prohibited for users based on the user group they belong to.

Use policy action scripts to get, update, or set values in cloud requests.

Create post-provision tasks for newly provisioned catalog items by defining subflows, scripts, CAPI calls, or resource operations. For efficiency, set up a post-provision operation, eliminating the need for manual invocation. This approach enhances time management, ensuring seamless execution of desired actions on the catalog item after resource provisioning.

Pre-provisioning operations streamline catalog item deployment by automating tasks like notifications, workflows, or scripts before provisioning. Configuring these operations eliminates manual steps and saves time. The system automatically executes specified actions when a provisioning request is submitted, such as notifying users about the impending item provisioning process.

The Cloud Provisioning and Governance Cloud API (CAPI) offers many providers, such as AWS and Azure, and products, such as EC2 instances. However, you can add products to existing providers for new types of cloud resources.

Resource blocks are the building blocks of cloud catalog items. Create a resource block for the Microsoft Azure Cloud Platform provider, based on a CI type from the CMDB.

If the blocks in the base system do not provide the cloud resources that you need to provision, you can create a custom resource block.

Execute a response processor for a subflow to get the subflow data back into a configuration item (CI). The response processor picks up the data, sends the data to the CMDB, which in turn puts the data in a CI.

You map a schedule profile to an instance schedule. The schedule profile applies to all newly-provisioned resources that use the profile. For example, a schedule profile can specify the days of the week and times of day when a stack should start and stop.

Create a subflow with the required input parameters that notifies Cloud Provisioning and Governance whether the flow completes successfully or not.

If you have subnets in your VMware vSphere account, create a cloud subnet record in the instance.

Create API key credential for Terraform account and supported Version Control System (VCS) accounts that contain the Terraform template repositories.

If you discover VMware networks and subnets, you must manually create a relationship between the two.

Create a workload provider type for each new configuration management provider. This information appears in the order catalog form as management attributes that your users can select when provisioning a virtual resource through a configuration management provider.

Extend the workflow engine to manage processes and automate things outside of an instance with Orchestration. Use the appropriate credentials required by Orchestration SSH and PowerShell activity elements: SSH requires SSH and PowerShell requires Windows.

Review the following considerations to on-board customers or companies in a domain separated instance, for Cloud Provisioning and Governance services.

Take advantage of the flow designer to automate your Day 2 operations. Quickly write a subflow that communicates with a Cloud API or a particular resource.

Several CAPI APIs are provided by default with the Cloud Provisioning and Governance application.

When a virtual machine is de-provisioned, delete the host record from Infoblox. Deleting the host record enables that IP address to be available and be reused for other virtual machines.

After you set up a service account, run Discovery to populate the datacenters in the account.

At any time, you can run Discovery on a datacenter to update the CMDB.

Run the Infrastructure as Code (IaC) discovery to identify the resources of the Terraform environment.

You can now schedule and perform discovery using Cloud Discovery Workspace and Discovery and Service Mapping Patterns.

Before configuring domain separation for customers, ensure that you review the following considerations ahead of provisioning cloud resources for each domain you are managing in the Cloud Provisioning and Governance application.

Domain separation is supported in Cloud Provisioning and Governance. Domain separation enables you to separate data, processes, and administrative tasks into logical groupings called domains. You can control several aspects of this separation, including which users can see and access data.

If any conrefs are broken, re-add them from the doc/source/reuse/domain-separation/domain-separation-overview.dita file. In the short description, edit the first sentence to state whether domain separation is supported or not and add the application name. Keep the conref at the end that describes domain separation.Domain separation is supported for Cloud Services Catalog Terraform Connector. Domain separation enables you to separate data, processes, and administrative tasks into logical groupings called domains. You can control several aspects of this separation, including which users can see and access data.

Several examples are provided to help you understand how to manipulate Cloud catalog order forms. These example cover blueprint rules, blueprint variables, and blueprint form UI groups.

You can execute your blueprint resource operations to run in a linear or in a parallel way.

Whether you're starting or expanding your implementation of Cloud Services Catalog Terraform Connector, learn more about the available features that help in provisioning and managing cloud resources across various public and private clouds.

To back up, move, or restore a policy, you can export and import the policy as an update set. The update set includes rules, conditions, actions, scripts, and script categories.

Use update sets to move a blueprint and its dependencies from one environment to another. Update sets let you group a blueprint and its dependencies into a named set and then move them as a unit to other systems for testing or deployment. For example, you can move a blueprint from a development environment to a production environment.

Use update sets to move a cloud API from one environment to another. Update sets let you group a cloud API and its dependencies into a named set. You can then move them as a unit to other systems for testing or deployment. For example, you can move a cloud API from a development environment to a production environment.

Use update sets to effortlessly transfer resource blocks and their dependencies between environments. Group them into a named set, facilitating seamless movement for testing or deployment. Simplify processes such as transferring a resource block from development to production, ensuring efficient and organized transitions across different systems.

Expressions in policy actions can set or override values. Expressions in blueprints can access attributes of resources and can map values to request form fields. Expressions are available in resource blocks, blueprints, policies, and anywhere that Cloud Provisioning and Governance allows scripts.

You can extend your existing guest interface to create a new operation. You can also create a new guest interface with its own operations, parameters, and inputs.

During Cloud Provisioning and Governance Day 1 setup, you added one service account to the cloud account. To compartmentalize your infrastructure or to include different datacenters, you can add another service account. A particular datacenter, however, cannot be selected in more than one service account in a cloud account.

You assign Cloud Provisioning and Governance roles to user groups and to individual users based on user activities and responsibilities.

To securely access data on your provider account, the Discovery process must present appropriate credentials. To make the credentials available to Discovery, you open the Google Cloud Console to identify the Google Cloud Platform project that will have programmatic access to your Google Cloud Platform data. You then securely store the credentials in a service account in your instance.

A service account is a secure record on your instance that stores the credential and access information for your provider account. Discovery uses the information to access your provider account to get data on each resource in each specified datacenter. A cloud account is the logical representation in Cloud Provisioning and Governance of all or part of your managed cloud infrastructure. A cloud account can include multiple service accounts — even service accounts from different providers. For each service account, you specify which datacenters to include in the cloud account.

Understand the high-level workflows for upgrading the Terraform environment.

You can install the Cloud Services Catalog Terraform Connector application (com.sn_cmp_terraform) if you have the admin role.If the application does NOT include demo data or it does NOT install related applications and plugins, delete or revise the following sentence:

Use an IP address management (IPAM) tool like Infoblox to manage cloud IP addresses, networks, and subnets within your cloud catalog offerings. However, it's important to note that this functionality is not supported with our template-based cloud catalogs.

Operations like Start/Stop, Deprovision, and ExecuteScript are called life-cycle operations or day-2 operations. When you request a life-cycle operation on a stack or resource, the system generates a change request. An approval policy specifies either that the change is auto-approved or that a user on the approver list must approve the change.

You can use the catalog items created in cloud management, in standard service portal.

You can specify attribute values for catalog items help cloud users to correctly provision catalog items. You can configure and manage attributes for provision, pre-provision, and post-provision operations.

You can configure operations for each interface of a resource block by specifying input parameters, steps, and output attributes. Input parameters hold values that the system requires to identify and manage a virtual resource, such as the datacenter and resource group that the resource is in.

You can view and manage your resources as well as the resources assigned to the group you belong to. If you belong to more than one group, you can view and manage all resources assigned to those groups.

Map credential types and service account fields Check for accuracy after IaC provider settings is updated to Credential mappings between Cloud Provisioning and Governance and Terraform using Credential Mapping.

To execute scripted actions during VM provisioning, you can map a script to an OS profile. The script runs on VMs that are created based on the image template in the OS profile.

Cloud Provisioning and Governance provides several JavaScript classes that make REST calls to cloud providers. These classes are called from MID Server script includes (for Azure by default) or from Java calls in the system (for AWS by default). If you create custom providers, interfaces, or CAPI APIs (for any cloud provider), you can use MID Server script includes to call the classes.

You can move the content in the Cloud Provisioning and Governance application from one environment to the other. For example, develop an application in an environment and then move the application and all its dependencies to another environment for testing or production.

Open the Cloud Orchestration Trail to debug and troubleshoot issues like a failed policy or failed Discovery of cloud resources.

Cloud orchestration records show you the orders that your instance processed for each attempted operation on a stack. They also show you the values of the fields that the user submitted through the Cloud User Portal. Use cloud orchestrations to troubleshoot issues that occur when a user provisions a cloud resource or runs another operation on an existing cloud resource.

Automatically discover the newly provisioned cloud resources and store their information in the ServiceNow ServiceNow Configuration Management Database (CMDB) by using pattern-based targeted discovery.

Configure life-cycle operations on cloud resources that are not provisioned using ServiceNow Cloud Provisioning and Governance. Provision resources and modify resource block operations to perform day-2 operations on cloud resources that are discovered using Cloud Discovery but not provisioned using Cloud Provisioning and Governance.

Triggers are events that set the policy engine in motion. For example, the on Catalog item request end trigger fires after a user submits a request form. When the trigger for a policy fires, the policy engine tests the conditions specified in the policy rule. If the conditions are met, the engine performs the actions specified in the rule.

A base system cloud policy, Lease End ServiceNow, uses the on Lease end trigger that fires when a virtual resource is near the lease end date. If the conditions in the policy rule are met, the policy engine sends a notification to the owner of the resource and performs operations on the resource.

A resource pool is a query or script that filters a table. You configure a resource pool to limit the values that are available to users when they request a catalog item.

This example illustrates how to populate the name of the stack that a user requests from the Cloud Provisioning and Governance catalog by utilizing the user's ID. The example uses a script include that you can call from a blueprint rule action.

Starting with the Paris release, the ServiceNow Cloud Management application was called ServiceNow Cloud Provisioning and Governance. The application is transformed into Cloud Services Catalog application providing improved and efficient management of the usage and life cycle of cloud resources.

Validate that Cloud Provisioning and Governance still works after you make any configuration change such as applying an upgrade or developing an application. Copy and customize these quick start tests to pass when using your instance-specific data.

The system calculates the quota allocated to you and the user groups to which you belong when you provision stacks. If quota limits are exceeded, the system either displays an error message or triggers a policy-based approval.

Quotas are limitations or requirements for groups and users on CIs or cloud resources. Use quotas to prevent wasteful resource usage in your cloud environment.

Create a policy to register IP addresses for AWS and Azure virtual machines in Infoblox, once these virtual machines are provisioned.

Remove a field from the Cloud Provisioning and Governance catalog form when the user belongs to a specific group.

The Cloud Provisioning and Governance application is available as a separate subscription and requires the Cloud Provisioning and Governance plugin (com.snc.cloud.mgmt).

Create a policy to reserve IP addresses for VMware vSphere virtual machines in Infoblox, at the time of provisioning the virtual machines.

Resource blocks act as a type of middleware component between catalog items, the Cloud API (CAPI), and the CMDB.

Use resource order controls to perform quota checks for template-based catalog items using quota definitions and policies. Quota limits enable you to control provisioning or ordering resources for users and groups. Configure policy actions to trigger notifications, an approval subflow, or both.

View quota limits to see how many resources you have consumed and how many you can provision based on quota limits set for you and your user group.

Response Mapping is the mechanism CMP uses to write back all the events and operations into CMDB.

The Create_Virtual_Server_Response_Processor script, which is available by default in Cloud Provisioning and Governance, is the response processor that handles the creation of AWS virtual machine CIs.

The Cloud Provisioning and Governance application creates a remediation or a catalog task when a request for a stack fails to provision. You can resubmit the failed request or assign it to the Cloud Operator group to handle it for you.

Add a custom schedule for Discovery to discover all resources in each datacenter in a service account and then update the CMDB with the new information.

Capacity limits place restrictions on the attributes of cloud resources such as the number of virtual machines, virtual CPUs, or aggregate storage. You can set limits on resources separately for each logical datacenter in a cloud account.

Create quota definitions and policies mapped to cloud-template based catalog items. Use policy rules and actions to trigger an approval subflow or notification when the quota limit defined for the group or user exceeds.

You can set default values for all users or you can populate fields with default values based on conditions. This example shows you how to set a default schedule profile and business service.

Set up Microsoft Azure Government Cloud on Cloud Provisioning and Governance for the first time. You can discover, provision, and manage Microsoft Azure Government Cloud resources using Cloud Provisioning and Governance, thereafter.

Create Terraform Enterprise or Terraform Cloud config provider in Cloud Provisioning and Governance. The config provider enables Cloud Provisioning and Governance to discover the workspaces and Version Control System (VCS) repositories attached to the Terraform organization.

Create a Terraform Open Source config provider in Cloud Provisioning and Governance. The Terraform Open Source config provider enables Cloud Provisioning and Governance to discover the Terraform Open Source config installables (Terraform templates) and detect changes in them.

Hosts that support the Host interface of a resource block are potential hosts for the resource block. You use the Host interface setting to further limit the options that are presented to the stack requester while selecting a host type.

Bindings represent endpoint relationships. For example, a storage volume might implement an endpoint type of Block EP (cmdb_ci_endpoint_block). A virtual server might consume an endpoint of that type. Bindings must support the Guest interface that is specified for the resource block.

The Cloud Provisioning and Governance application supports integration with continuous delivery solutions (also known as configuration management). Ansible is supported as the default config management provider.

In any request for a catalog item using Terraform templates, the required Location value specifies the datacenter or region where to provision the configuration items and stacks. You can use a variable named region in the Terraform template to map to the Location field on the request form.

Create a JSON file to store Terraform template variables and map them to discovered resources, pools, filters, and catalog item provision form fields.

Add minor or patch versions of the Terraform (Terraform Open Source, Terraform Enterprise, or Terraform Cloud) to the workload provider type record.

The Cloud Provisioning and Governance application provides several tools to help you troubleshoot errors. You might encounter errors during the Discovery of cloud accounts, the provisioning and managing of cloud resources, and the updating of the CMDB.

You can use resource pools with blueprints to limit the choices on the cloud catalog request form.

The Cloud Operations Dashboard breaks down cloud service requests from your end users and cloud stacks that you offer in the Cloud User Portal.

Root Cause Analysis reports help you troubleshoot issues with Cloud Provisioning and Governance. Use the reports to view details about the Cloud Orchestration Trail and the Cloud API Trail.

You can now discover multiple Terraform configurations from one repository, at any folder level with Terraform Enterprise Config Provider.

You must set up and use the user groups in Cloud Provisioning and Governance as a part of the day-2 task.

Understand the high-level use cases and usage workflows for the Cloud Services Catalog Terraform Connector application.

The AllowedPattern property in an Azure Resource Manager (ARM) and CloudFormation (CF) template performs input validation before sending a provisioning request.

You assign Cloud Provisioning and Governance roles to user groups and to individual users based on user activities and responsibilities.

A cloud account is the logical representation in Cloud Provisioning and Governance of all or part of your managed cloud infrastructure. A cloud account can include multiple service accounts — even service accounts from different providers. For each service account, you specify which datacenters to include in the cloud account.

To securely access data on your provider account, the Discovery process must present appropriate credentials. To make the credentials available to Discovery, you first create an account in the VMware Console. You then securely store the credentials in a service account in your instance.

This example walks you through the components of Cloud Provisioning and Governance that function during the provisioning of a virtual machine in an Azure datacenter. Topics covered include blueprints, resource blocks, the Cloud API (CAPI), and MID Server script includes.

This example walks you through the components of Cloud Provisioning and Governance that function during the provisioning of a virtual machine in an AWS datacenter. Topics covered include blueprints, resource blocks, the Cloud API (CAPI), and MID Server script includes.