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.
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:
((secret:v1:AAFUlkp5nI7bKx0RxSgbUmpEqqXmiC+Bd4Gb8UgSFScF+h+rAViHCg==))"
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.
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
/ref/property-groups/hostname_credentials : hostname (string) & template_user (string)
/ref/property-groups/default_minion : os (string), flavor(string) & minion(boolean)vcfqdn (string)
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.
Conclusion:
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
Share ABX Actions in Projects and Subscriptions.
