Looking for resources about Secure Properties in Cloud Assembly I bumped into an internal VMware blog by Kristina Zhelyazkova which explains it extremely well and I thought our customers and partners could benefit greatly from that blog, so with the appropriate permission I am transcribing the blog here for all public benefit, and once again huge kudos to Kristina! for putting it together, here it is:
I’m excited to present to you a new capability in vRealize Automation available since the December vRA Cloud release. It is called “Secure Properties” and allows users to mark their data as sensitive (passwords, codes etc.). We ensure that this sensitive data is protected by encrypting it, storing it in encrypted format and not showing it in plaintext. Once encrypted, the value will be returned in encrypted format in the API responses and will be shown as stars or in encrypted format in the UI. The value will be decrypted only when it is sent to the Cloud Provider (for example, AWS, GCP or vSphere) to ensure the data is still usable.
In this blog I’ll explore 2 different scenarios. The first one will be via the UI and the second one via the Cloud Assembly IaaS API.
The first scenario includes:
- Creating an Image Mapping with cloud config which displays a sensitive message
- Creating a Project with encrypted property containing vIDM password
- Creating a Cloud Template that uses the created Project and Image Mapping and describes a machine with cloud config which allows remote access
- Deploying the created Cloud Template
- Verifying all sensitive data is encrypted
- Verifying successful login to the machine and that the message is displayed
The second scenario includes:
- Creating а Project with encrypted property containing Cost Centre password via Cloud Assembly IaaS API
- Provisioning a machine with remote access and encrypted custom property via Cloud Assembly IaaS API
- Verifying all sensitive data is encrypted
- Verifying successful login to the machine
Deploy a Cloud Template for a VM with sensitive information
I have added an Azure Cloud Account, created a Cloud Zone and added a “small” Flavor Mapping – nothing special here.
Now, let’s add an Image Mapping with cloud config. It is a simple cloud config to display a message which is marked as sensitive:
As described in the pop-up, if you want to mark some part of the Image Mapping cloud config as sensitive, you just need to add “((sensitive:” as prefix and “))” as suffix. You can edit the cloud config freely including the sensitive data until you save the Image Mapping – after that, the sensitive data will be encrypted and the cloud config from my example will look similar to the following string:
The same plaintext value encrypted on another occasion, will not look the “same” – it will start with “((secret:” and end with “))” again but the middle, which is the actual encrypted value, will look different. After saving, the plaintext message is no longer visible and you can’t edit it. If you want to change it, you’ll have to delete the entire “((secret:v1:AAEhh1sjJyB91lno81cgfQ9nIyIesQHV2KUr8cSFIVmb8ZWitc+J3A==))” and enter a new message (using the sensitive format, if you want us to encrypt it again).
Let’s continue with creating a Project and adding the Azure Cloud Zone in it. The more interesting part here is adding vIDM password as custom property of the Project:
The vIDM password will be added as custom property to the machine I’m going to provision. I don’t want this password to be visible so I’ll select the “Encrypted” checkbox next to it and the value will be masked with stars:
Oops. I just remembered there was “!” at the end of the password. No problem! I can still edit the password if I uncheck the box next to it before saving the changes to the project. Now, let’s save the Project with the custom property. If I open the Project and uncheck the “Encrypted” checkbox now, I’m no longer able to see the plaintext value – I should enter a new value for the property or cancel editing the Project to preserve the old encrypted value.
Ok. Now I’m ready to create my Cloud Template in this Project. I want to deploy a machine with cloud config that allows me to log into the machine with a password. I want my password to be protected so I’ll create a Cloud Template Input for it and mark it as encrypted like this:
By doing this, I can refer the Input in the Code of my Cloud Template and my password will be encrypted. I use an image that matches the one I created with the cloud config that displays a message and also add cloud config in which I refer to the “sshPassword” input:
Great! I’m ready to deploy. A wizard appears in which I give the Deployment a name in the first step and enter my password in the second:
The password will appear as stars but I’ll tell you my secret – it’s “theWall!123”. It’s name is “SSH password” because this is what I entered for “Display name” when I created the input as shown above.
Perfect! We have a successful deployment:
Now, let’s verify all the information we marked as sensitive is encrypted. First, let’s see how the cloud config looks:
We see the entire cloud config here which is the result from merging the cloud config from the Cloud Template and the one from the Image Mapping. As you can see, both the password and the message are encrypted.
Good so far. Let’s expand the “Custom properties” section and find the vIDM password property I added in the Project’s custom properties. It’s value is not visible – it’s masked with stars:
Great! All my sensitive data is protected.
One more thing I’ll check – I should be able to log into my machine with the username “krisi” I specified in the Cloud Template and the password “theWall!123”. As visible in one of the screenshots above, the IP address of my machine is “104.42.173.234”. Let’s try to log in:
Success! I’m in. So I verified the password is encrypted in vRA but I can still log in with the plaintext value. You can also see the name of the machine matches the “Resource name” we saw in vRA in one of the screenshots.
And the last thing – let’s make sure the command for displaying the message was successfully executed. I can do that by looking into the file which contains the output from the cloud config:
Close to the end of the file I can see my welcoming message which I showed you in the first screenshot:
Perfect! The message is visible here in plaintext and we already saw it is encrypted in vRA – this is what we expected.
Provision a VM with sensitive information using IaaS API
Now, let’s do something similar via IaaS API.
We’ll use the same Cloud Account, Cloud Zone, Image and Flavor Mapping from the previous scenario.
First, let’s create a Project with a sensitive property with the Cost Center password and assign the Cloud Zone to it with this API call:
As you noticed, we are using the same pattern to mark the property’s value as sensitive as we did in the cloud config in the previous example. The only difference is that when it comes to custom properties, the entire value should be marked as sensitive, not only parts of it like in the cloud config.
Here’s the response:
Good! The Project is created successfully and looks as expected. The password is encrypted in the response and again, the encrypted form has the prefix and suffix you saw in the previous scenario.
Let’s go ahead and provision a machine in this Project.
We specify a remote access username and password which we’ll use later to connect to the machine via SSH. But wait… Isn’t the password something sensitive, too? That’s right! Even if you don’t mark your remote access password as sensitive, like I did here, it will be encrypted because it’s generally considered as sensitive information. We have more sensitive data in the body – a custom property’s value is marked with the prefix and suffix. The response is a request tracker, as usual:
And we wait until the machine is ready:
Success! Let’s make another call to obtain the machine:
The part of the body we see contains what we’re interested in – address, cloud config (here, it’s called “bootConfig”) and custom properties.
Let’s check if all of our sensitive data is protected.
The remote access information is turned into cloud config you see in “content” in “bootConfig”. This cloud config will allow remote access authentication with the username and password we defined in IaaS API provisioning request’s body. As I promised, the password is encrypted – you can see that in the value of “passwd”. Hmm… but if you look closely, you’ll notice there is something else encrypted in the cloud config just at the end. It’s the argument of echo command. Where did this come from? Oh, yes! We’re using the same Image Mapping from the previous scenario and if you remember, we added cloud config to it to display a sensitive message. This is that message in encrypted form! But if you compare it to the encrypted form of the message we saw in the UI, it does not look the same. I already explained why in the previous example – the same value encrypted 2 different times will result in 2 different values.
Now, let’s have a look at the custom properties of the machine. We see the Cost Center password coming from the Project is encrypted and the sensitive property we defined in the body of the IaaS API provisioning request is also encrypted. Great! Everything we need is encrypted.
And finally, let’s verify we can log into the machine with the username and plaintext password like we did in the previous scenario. The address used in the ssh command is visible in the IaaS API response above. Then, when I got prompted for the password, I entered “my-pass10!”, not the encrypted form and…
Success! I got in! And using the same command I did in the previous example, I can verify the same message is displayed here as it was part of the Image Mapping cloud config:
In conclusion, this feature will allow you to mark your data as sensitive on different steps of your way and make sure the plaintext value will not be visible anywhere. However, we support this only in the cases we identified as necessary. The full list of what is supported:
- when provisioning resources: You can mark some parts of the data as sensitive when provisioning resources. The resources include machines, load balancers, disks, networks, security groups and compute gateways. You can do it no matter if using Cloud Templates or IaaS API for provisioning. In the case of Cloud Templates, you can add an encrypted Input in the Cloud Template and refer it anywhere in the Code. However, we ONLY support:
- encryption of custom properties’ values (for example, image and flavor are NOT custom properties) for all types of resources. The entire value should be marked as sensitive.
- encryption of remote access password for machines. The entire value should be marked as sensitive. This is considered sensitive by default, which means that it will be encrypted even if you don’t mark it as sensitive.
- encryption of sensitive parts of the cloud config. You can mark parts of the cloud config as sensitive. For IaaS API, the property is called “bootConfig”.
Nothing outside of what is listed here supports encryption when provisioning.
- when creating or updating Projects: You can mark properties of the Project as sensitive. This can be done when you create a Project or update it. This can be done via the UI or IaaS API. It can also be done directly via the Projects API in a similar way to IaaS API.
Nothing outside of the properties supports encryption for Projects. - when updating a deployed machine via IaaS API: You can mark custom properties’ values of the machine as sensitive in the body of the PATCH request you send to IaaS API. This is supported only for machines deployed via vRA and is NOT supported for discovered machines. For discovered machines, there is the option to onboard the machine and after that, you can add sensitive properties to it.
Nothing outside of custom properties supports encryption during update of a machine. Only deployed machines support encryption. - when creating or updating image mappings: You can mark parts of the cloud config as sensitive when they create or update Image Mappings (called Image Profiles in IaaS API). In the UI, you can enter your cloud config and mark parts of it as sensitive the same way you do it via IaaS API – by using the special prefix and suffix.
Nothing outside of cloud config supports encryption for image mappings
And this is everything you need to know. Now go ahead and try it out!
Related Links:
Cloud Assembly and ABX Secrets (and how to use them for installing vRealize SaltStack Minion Agents).
Share ABX Actions in Projects and Subscriptions.
