Getty Images/iStockphoto
An intro to using vRA Custom Resources
VRealize Automation offers Custom Resources to enable a vRA user to create a variety of user objects to simplify management of those users.
VRealize Automation 8.1 brought back Custom Resources as a feature. Custom Resources enables you to create objects that vRA recognizes and that any vRA user can then manage, which simplifies a variety of workflows. In essence, it enables you to manage any type of object previously only manageable through a vRealize Orchestrator plugin through vRealize Automation.
Prior to the release of vRealize Automation 8.1, you could expose vRealize Orchestrator workflows through the catalog. This meant you could expose a workflow to a vRA user so that user could perform tasks such as creating a user object in active directory, running a script through SSH on a host or creating a database on a database server. You can expose any workflow from vRealize Orchestrator in the catalog.
For example, you can create an Active Directory user object that enables a vRA user to manage an AD user. Normally, a vRA user cannot access AD management tools and AD users don't exist in vRA outside the box. Those AD users can't easily change their passwords or add themselves to a group. If you expose a workflow to a vRA user to change passwords or add users to a group by placing them in the Service Broker Catalog, anyone can modify all other users, which presents significant risks. By limiting those actions to a single user object that the vRA user creates, you can then from there instead of from unmanageable vRealize Orchestrator workflows.
What are Custom Resources?
Once you deploy vRA, you can create several object types, including a vSphere machine, an AWS machine or a network in NSX. You can add these types of resources to a blueprint, which then enables your vRA users to create these types of resources.
For example, you can create an AD Custom Resource and name it something along the lines of Custom.ad:user. The name must use the "Custom" prefix, but you can choose the rest of the name. Include the external type -- e.g., ad:user -- in the name to help you keep track easier. The ad-prefix comes from the Active Directory plugin. You can also create relevant vCenter objects with the vCenter plugin using the "vc" prefix.
You can also link between two required workflows in order to create or destroy an object of this type.
Then add actions that vRA users can use for these objects. In the case of an Active Directory user, adding a user to a group or are useful actions. To avoid enabling anyone to add a user to any group, configure a default value for the group that enables a vRA user to only add a user object to a certain group. Use the Request Parameters function to open the custom form designer that contains that feature.
What to do with a Custom Resource
Once you add a Custom Resource, it becomes available to add to a blueprint. The fields should all be available to the user requesting the blueprint, but you can use the custom forms designer to designate certain fields as read-only or invisible.
After deploying the resource, the Active Directory User Object shows up in the topology overview of the deployment. Because of the destroy workflow configured for the Custom Resource, when you delete a deployment, this automatically removes the user object from Active Directory as well.
You can add Resource Actions not only to Custom Resources but also to existing resource types in vRA. This enables you to expand the existing Day 2 operations of a machine with your own actions based on vRealize Orchestrator workflows.
Caption: In the example in the picture below we have created an action that adds a feature to a Cloud vSphere Machine to run the workflow to add a virtual machine to a folder.
Whenever an existing action doesn't do what you need or when actions are unavailable, you can now create those actions yourself.
