vRealize Cloud Management Platform vRealize Orchestrator

Extending vRealize Automation Custom Forms with vRealize Orchestrator

Within the vRealize Automation Service Broker is the Custom Forms designer which, much like previous versions of vRealize Automation, allows catalog administrators to create custom forms. These can be used to create a more dynamic and engaging user experience, especially for business users who may not have the knowledge (or desire) to make technical decisions.

In this blog post I’m going to use the Custom Forms feature to look up values in an external data source. My external data source will be a Hashicorp Vault server – if you’re not familiar with Vault you can read more on the introduction page, but simply put:

Vault is a tool for securely accessing secrets. A secret is anything that you want to tightly control access to, such as API keys, passwords, or certificates. Vault provides a unified interface to any secret, while providing tight access control and recording a detailed audit log.

However, the data source isn’t so important as the principle, leveraging an external data source to provide inputs in a vRealize Automation form. I’ve broken down the process into four steps:

    1. Create a blueprint with inputs for user creation and SSH keys
    2. Configure a Vault Secrets Engine with Secret Data
    3. Create vRealize Orchestrator Actions to retrieve and return Secret Data
    4. Customise the Service Broker form

Create a blueprint with inputs for user creation and SSH keys

Firstly, I’ve created a simple blueprint to deploy an Ubuntu VM onto my vSphere environment. This particular blueprint deploys an on-demand NSX network too, but that’s not required for this to work. The two important bits of configuration here are the inputs (user and sshkey) which are used to capture the custom user and key, and the remoteAccess section, which are used to take the inputs and configure the new user for public key authentication with the supplied public key.

Once created, the blueprint is versioned and released to the catalog.

Configure a Vault Secrets Engine with Secret Data

I’ve got a Vault server running in my lab under https://vault.definit.local:8200. I’ve created a new Secrets Engine called “vra”, with a Secret called “ssh” under which I’ve stored 3 user names and their SSH keys.

In addition to this I’ve created a new user called “vra” and a new access policy called “allow-vra-access”, which gives the User access to the Secret. The configuration of a Vault server is outside the scope of this post, but there are plenty of online guides available if you’re interested.

Vault Secrets

Create vRealize Orchestrator Actions to retrieve and return Secret Data

There are a few steps required for vRealize Orchestrator to query the Vault API. The first is authentication – access to the Secrets API is granted through the issuing of a Token, which is returned by the authentication API. The second step is to query the Secret API using the Token for a list of users, which we will return to the Custom Form to display in a drop down. The final step is an action to take a specific user name and query the Vault Secret API for the specific user’s SSH key.

Action getVaultToken(String vaultUser, SecureString vaultPassword, String vaultServer, String vaultPort)

getVaultToken has four inputs, vaultUservaultPasswordvaultServer and vaultPort, and authenticates with the Vault API to return a SecureString containing the Vault Token.

getVaultToken inputs/outputs

Action getVaultSecretData(String vaultServer, String vaultPort, String vaultSecretPath, SecureString vaultToken)

getVaultSecretData has four inputs, vaultServervaultPortvaultSecretPath and vaultToken, and makes an API call to the vaultSecretPath using the vaultToken for authentication. It returns a JSON string of the Secret Data.

Action getVaultSecretUserNameList()

Uses the previous two Actions and returns a String array of the Secret Data names – the user names.

getVaultSecretUserNameList inputs/outputs

Action getVaultSecretUserNameSshKey(String userName)

Returns the public SSH key from the Vault Secret based on the userName supplied

getVaultSecretUserNameSshKey inputs/outputs

Customise the Service Broker form

The final step brings together the Actions to customise the form. Within the Service Broker Content & Polices section, locate the blueprint on the Content page and select the “Customize form” menu item:

Custom Forms - customize

Customise the following:

  • Select the User input
    • Change the Appearance > Display Type to “Dropdown”
    • Change the Values > Value option to “External source”, and select the “getVaultSecretUserNameList” action
  • Select the SshKey input
    • Change the Appearance > Read-only to “Yes”
    • Change the Values > Default value option to “External source”, select the “getVaultSecretUserNameSshKey” action, and configure the Action input to the User Field
    • (optional) Change the Appearance > Visible option to “No” to hide the field, but still capture the value when submitting the request.

Custom Form Input Configuration - User Custom Form Input Configuration - SshKey

Test the Custom Form

We can now test that the form, initially the User field will be blank with the values returned from getVaultSecretUserNameList available to select from the dropdown. Once a value has been selected, getVaultSecretUserNameSshKey will take the value selected in the User dropdown and look up the Public SSH key relating to that User.

Custom Form with vRA Lookup

As you can probably see, bringing the multi-tool flexibility of vRealize Orchestrator Actions into Service Broker Custom Forms can allow you to create a powerful guided user experience, or dynamically build out input values based on a range of decisions.


5 comments have been added so far

  1. Correct me if i am mistake but there is no way to view execution runs of these workflows to help debug like integrations?

    1. Action executions are not directly visible in the vRO client – but you can view the logs, or forward them to Log Insight, or another syslog server. You can also now run and debug the vRO action directly in the client.

Leave a Reply

Your email address will not be published. Required fields are marked *