Cloud Management Platform Cloud Automation vRealize vRealize Automation vRealize Suite

Cloud Assembly and ABX Secrets (and how to use them for installing vRealize SaltStack Minion Agents).

Speaking to customers and partners, we received amazing feedback about vRealize Automation SaltStack however, when discussing the default SaltStack Agent default initialization some indicated that it could be a challenge in their environments and they would like to try an alternative approach, luckily when it comes to flexibility, vRealize Automation is really exceptional, so our team put together a second option via ABX and PowerShell.

Furthermore, with the introduction of vRealize Automation 8.3 and Cloud you can now apply secret, encrypted values to Cloud Assembly cloud template and Action-based extensibility ( ABX ) Scripts. which protects the sensitive data we used to access the workloads and servers for this solution,  so here it is what we did, but let’s get started by reviewing this new secret management capability.

A secret Cloud Assembly property is a reusable, encrypted value that project users may add to their cloud template designs.

Secure access keys and credentials are typical examples of secret properties. Once created and saved, a secret property value can never be unencrypted or read. With Cloud Assembly, you can create and store secrets for use in extensibility actions.

Cloud Assembly Infrastructure Secrets

Adding new Secrets is a very simple process, you just need to select the Project on which the secret will be used, provide a name for the secret property without spaces or special characters, the associated value and as best practice, a brief description.

At this point, all you need to do is referring to it directly from anywhere in your Cloud Assembly cloud template by using the prefix “secret.” and the name of your property, here’s an example including also the previous entries:

BTW, you may know that Custom Properties can also be defined at the project level but what it is new is that they can be also be encrypted now:


Please note that even if you call vRealize Automation‘s APIs, the secrets will not be exposed but presented encrypted with the following format:


Switching gears, with Extensibility Action Secrets, you can also add encrypted input values to your extensibility actions. Once again, encryption is useful for use cases where your Script inputs are managing sensitive data, such as passwords and certificates. Secrets are available for all FaaS providers and runtimes.

Adding an Extensibility Action Secrets is also very direct, just go to Extensibility, Actions and a new option Manage Action Secrets is available:



Here as the name indicates you can manage your Extensibility Action Secrets, e.g. Add more or edit existing ones and they are essentially a Name / Value definition.




Secrets employs the context.getSecret() function to run as part of your script. This function uses the name of secret as a parameter. For example, you might use an extensibility action secret named vcPassword as an encrypted input parameter in your action, e.g. context.getSecret(inputs["vcPassword"]) (Python) or $context.getSecret($inputs.vcPassword)(Powershell) and so on


You may notice that at this release, we’re using two different “Secret Repositories” but there are plans to consolidate all in one single repository, also this Secret Management Service is for self-consumption, it is not exposed to third-party services at the moment.


Excellent, so let’s install vRealize Automation SaltStack Agent for Linux and Windows workloads via Cloud Assembly cloud template and leverage ABX and PowerShell plus Secrets, In a nutshell, we will take advantage of VM Tools via vCenter to execute PowerShell Commands that install and initialize the vRealize Automation SaltStack Agent regardless of the OS Type.


This means, I will need to use the default vCenter IP + credentials as well as my vRealize Automation SaltStack IP , all of which is sensitive data that I don’t want to expose to anyone, hence the use of Secrets, please note that the cloud template also takes advantage of vSphere Customization Specification to provide the very minimum to execute PowerShell Commands (once we initialize vRealize Automation SaltStack Agent, it will take care of the whole configuration management in our server).


Having said that,  I created a Cloud Template and an ABX Action (referenced above), you can find both source code in this GitLab repository: ca_abx_secrets (ABX Action is zipped so you can simply import it in your local vRealize Automation 8.3 or simply unzip to see the PowerShell Script Code, which BTW was mainly crafted by Chris I just tweaked it a bit by adding the secret portion).


You may notice in the Cloud Template that the some of the inputs are actually defined as Property Groups, you can learn more about it at Vicent’s blog: vRealize Automation Property Groups, essentially I collect all this input :


Property Group: /ref/property-groups/hostname_credentials : hostname (string) & template_user (string)


Property Group: /ref/property-groups/default_minion : os (string), flavor(string) & minion(boolean)
Property: vcfqdn (string)


and defined these secrets (refer to the image at top):


template_password_linux (the default credentials for my Ubuntu Image)

template_password_windows (the default credentials for my Ubuntu Image)

Now I decided that some of the secrets only need to be handled in ABX side, they are:

vcUsername (the vCenter username credentials)

vcPassword (the vCenter password credentials)

vrss (the default vRealize Automation SaltStack IP or FQDN)

From this point, all I need to do is to pass the input from lines above to the ABX PowerShell Script, please note the use of the context.getSecret() function for accessing the specific type of property:

function Handler($context, $inputs) {
$inputsString = $inputs | ConvertTo-Json -Compress
$tmpl_pass = $context.getSecret($inputs.customProperties.tmpl_pass)
$tmpl_user = $inputs.customProperties.tmpl_user
$mioSegreto = $context.getSecret($inputs.customProperties.mioSegreto)
$vcuser = $context.getSecret($inputs.vcUsername)
$vcpassword = $context.getSecret($inputs.vcPassword)
$vcfqdn = $context.getSecret($inputs.customProperties.vcfqdn)
$vrss = $context.getSecret($inputs.vrss)
$name = $inputs.resourceNames[0]
$hostname = $inputs.customProperties.hostname

You can  explore further the ABX PowerShell Script at the ca_abx_secrets but basically, we just connect to the appropriate vCenter, wait until VMware Tools are running, discover the OS Type and execute the agent install, including configuration.

Also, since this ABX action is called during provision, don’t forget to add an Extensibility Subscription for the Event Topic Compute post provision and associate to our ABX action, so it can be fired up at the right time and access the appropriate data we need, in fact, you may have noticed above minion(boolean) , I have it for mapping the Cloud Template’s custom property min_install: '${input.default_minion.minion == false ? "No": "Yes"}' to give the user the ability to install or not the Agent, this property is called and evaluated by the subscription’s condition:

(BTW, it could have been enough to leave “false” for my “min_install” property but I wanted to use a different string to evaluate)

With all this in place we can deploy our workload,

You may notice that my hostname is oc-cool-workload, that’s because vRealize Automation SaltStack is pre-configured to accept & register any server having “oc-cool” then running a “State” which will install a whole application, all this possible because of the Agent we’re installing, if you want to learn more about, check out this blog vRealize Automation SaltStack Config – A Technical Overview.

Inspecting the deployment, you may see our Secret: template_password_linux was mapped to a custom property templ_pass per our Cloud template:

tmpl_pass: '${input.default_minion.os == "Linux" ? secret.template_password_linux: secret.template_password_windows}'

but the actual password is hidden at the deployment:

When we inspect our ABX execution details, you could also fine the custom property but the actual password is hashed and presented with the same format as used in the API calls:

Note also the Script body, since we’re using only variables, there is not sensitive information displayed

In addition, at the log, you can witness how the vCenter / vRSS credentials and IP information is consumed by the Script but not exposed at the logs

And finally, we could verify that because the vRealize Automation SaltStack Agent was installed and registered with our vRealize Automation SaltStack (data fetched from our secrets) the application state was triggered:

The same execution is possible for Windows Servers by simply selecting the OS Distro : Windows and providing the Template User: Administrator.


vRealize Automation 8.3 and Cloud’s Secrets capabilities enhance the existing management of sensitive data at all levels without the need to rely on external Secret Repository Server. So now that you are familiar with this feature, don’t tell anyone, because you know, it is a secret….me kidding please spread the word, tell your cousins, your neighbors and colleagues, they will appreciate it.

Related Links:

vRealize Automation Cloud Assembly’s new feature Secure Properties

Leverage vRealize Automation’s Action Based eXtensibility (ABX), Event Broker Service (EBS) & APIs for Email customized notifications.

Share ABX Actions in Projects and Subscriptions.

vRealize Automation ABX Flows.

vRealize Automation SaltStack Blogs.


One comment has been added so far

Leave a Reply

Your email address will not be published.