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:
- Create a blueprint with inputs for user creation and SSH keys
- Configure a Vault Secrets Engine with Secret Data
- Create vRealize Orchestrator Actions to retrieve and return Secret Data
- 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.
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,
vaultPort, and authenticates with the Vault API to return a SecureString containing the Vault Token.
Action getVaultSecretData(String vaultServer, String vaultPort, String vaultSecretPath, SecureString vaultToken)
vaultToken, and makes an API call to the
vaultTokenfor authentication. It returns a JSON string of the Secret Data.
Uses the previous two Actions and returns a String array of the Secret Data names – the user names.
Action getVaultSecretUserNameSshKey(String userName)
Returns the public SSH key from the Vault Secret based on the
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:
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.
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.
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
Great info, Sam.
Correct me if i am mistake but there is no way to view execution runs of these workflows to help debug like integrations?
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.
Can you really use a syslog server? Thought Log Insight was pretty much the only option.
You can indeed – https://docs.vmware.com/en/vRealize-Orchestrator/8.2/com.vmware.vrealize.orchestrator-install-config.doc/GUID-4A387D7F-8E9F-4C8B-A68D-618769B6DE41.html