Change Requests for XaaS Resources

This topic discusses design considerations for change requests that target XaaS (Anything-as-a-Service) resources, which can include:

Generic resources that belong to AWS stacks, GCP deployments, or Azure Resource Groups.
Terraform resources. In Commander, the infrastructure objects that belong to Terraform backends are also non-inventoried, generic resources.

To view the XaaS resources that belong to an AWS Stack, GCP Deployment, or Azure Resource Group, select one of those cloud deployments in the Admin Portal's Infrastructure or Application tree views. The resources that belong to those cloud deployments will be listed in the Resources tab.
To view the resources that belong to a Terraform backend, in the Admin Portal's Inventory tree, click the Terraform tab, go to the appropriate backend, then click the Resources tab.

To create change requests for XaaS resources, you must select XaaS Resource as the change request's target type. You can also add workflows to those change requests that will perform tasks on the resources you want to target. For more information, see Create Change Requests.

For an example of how to create change requests for XaaS resources, see Snow Software's public Cloud Management Integrations repository on GitHub.

View XaaS resources

To view the XaaS resources that belong to a Stack, GCP Deployment, or Azure Resource Group, select one of those cloud deployments in the Admin Portal's Infrastructure or Application views. The resources that belong to those cloud deployments will be listed in the Resources tab.
You can determine if a displayed XaaS resource is inventoried in the following ways:
- A distinct icon is displayed in the Type column.
- If you double-click a resource, a details page will display if the resource is inventoried. From that page you can access further actions or change requests for the resource.
To view the resources that belong to a Terraform backend, in the Admin Portal's Inventory tree, click the Terraform tab, go to the appropriate backend, then click the Resources tab.

Generic resources

Change requests for XaaS resources are only available for use with non-inventoried, generic resources. Therefore, when designing change requests for XaaS resources, it's helpful to know if the resources are inventoried by Commander or whether they are non-inventoried, generic resources.

Inventoried resources in Commander are well-known objects in your cloud accounts' virtualized infrastructure that can be directly managed through the Admin Portal.

Non-inventoried resources are generic and they can't be managed directly through the Admin Portal; this is why XaaS change requests that use custom workflows to modify those resources are so useful.

Terraform resources are always considered to be generic resources in Commander. Therefore, to change these resources through Commander, you must use change requests that use custom workflows.

Resources that belong to AWS stacks, GCP deployments, and Azure Resource Groups are generic, with the exception of the following, which are inventoried:

VMs
databases
load balancers
auto scaling groups

These inventoried resources can be modified through actions in the Admin Portal and the Service Portal. All other resources that are part of a Stack, GCP Deployment, or Azure Resource Group can only be modified through change requests that use custom workflows. For example, you could create a custom change request that includes a workflow that would add requesters to the access list of an S3 bucket or an Azure blob storage.

Workflow variables

Many existing Commander variables can be used for approval and completion workflows that are configured for generic resources that belong to Stacks, GCP Deployments, Azure Resource Groups, or Terraform. For example, to implement an approval email that's sent out for the change request, you could use #{target.cloudAccount.address}, for the address of the cloud account that a resource is running on, and #{target.primaryOwner.email}, for the email of the resource's primary owner.

Note that not all approval and completion workflow variables are applicable to generic resources. Click below for a complete list of variables that are available to generic resources.

Variables available for generic resources

Category	Variable Name	Expression
Commander	Directory	#{system.directory}
	IP Address	#{system.address}
	Port	#{system.port}
Infrastructure	Cloud Account Address	#{target.cloudAccount.address}
	Cloud Account Name	#{target.cloudAccount.name}
	Cloud Account Tenant ID	#{target.cloudAccount.tenantId}
	Cloud Account Type	#{target.cloudAccount.type}
	Region	#{target.region.name}
Target	Context	#{target.context}
	Management Server Type	#{target.mediatorType}
	Primary Owner Email	#{target.primaryOwner.email}
	Organization ID	#{target.organization.id}
	Target ID	#{target.id}
	Type	#{target.type}
Request	Date Submitted	#{request.requestDate}
	Form Name	#{request.form.name}
	Request ID	#{request.id}
Requester	Organization Contact Emails	#{request.requester.organization.email}
	Organization Name	#{request.requester.organization.name}
	Parent Organization Contact Emails	#{request.requester.parentOrganization.email}
	Parent Organization Name	#{request.requester.parentOrganization.name}
	Requester Email	#{request.requester.email}
	Requester Full Name	#{request.requester.name}
	Requester UserId	#{request.requester.userId}

For more details on these variables, see Approval Workflow Variables for Change Requests and Completion Workflow Variables for Change Requests.

Context variables

The #{target.context} variable can be used with generic resources to return JSON files, which provide the identifying resource name and type for each resource. For example, you could use the context variable in a script added to a workflow so that the workflow will know the resource they're operating on.

When the context variable is used for a Terraform resource, a resource fragment is also included in the JSON file; this provides configuration information specific to the Terraform resource.

For convenience, you can also use the #{target.context.type} variable, which resolves on just the context type provided in the JSON (for example, a load balancer provisioned through Terraform), and the #{target.context.name} variable, which resolves on just the context name (for example, the given name of one of many provisioned load balancers).

The context variables can also be used in conditional expressions that you can add to change requests. Adding conditional expressions to change requests allows you to control whether users can make request changes on given resources — the context variables will provide the resources' identifying name and type, and this information can be used to filter the changes that can be requested. For example, you could limit a change resource configured to decommission load balancers to only be available for load balancers provisioned on AWS through Terraform.

For more information, see Make Change Requests Conditional.

Environment variables for AWS and Azure credentials

If your workflows use script steps to act on resources within AWS and Azure cloud accounts, they will require credentials for those cloud accounts. If the credentials are set as environment variables, they can be retrieved through variables for the execution of the script.

For AWS cloud accounts, the access key ID and secret access key are required.
For Azure cloud accounts, the subscription ID, API key, tenant ID, and application ID are required.

For more information, see Use Environment Variables for Credentials.

Terraform resource credentials

To make changes to resources deployed through Terraform templates using workflow steps, credentials are required to give the workflow access to the cloud account where the resources are deployed.

One option is to add any required credentials to Commander's protected credential store. Then, in a completion workflow, these credentials can be retrieved through a REST call and subsequently passed into other steps as required.

For example, to make resource changes, a workflow may need credentials to SSH into a Terraform host, credentials for the Terraform Cloud account, and credentials for the cloud account that provides the backing cloud infrastructure for the deployment (for example, an AWS Cloud Account).

For information on how to add credentials to Commander, see Manage Credentials.