In this blog I’ll explore the new Secret capability in vRealize Automation Cloud. The use case includes the following:

• Deploy a CentOS 8 machine
• Store the new user password and SSH key in a Secret
• Configure the machine using Cloud-Init
  • Assign the password and SSH key from a vRA Cloud Secret
• Verify the password and SSH key assignment.

First, add two Secrets. Go to Infrastructure -> Secrets, then click NEW SECRET.

The first one will be the SSH key. Find your project, give it a name, then paste in the key. Click CREATE to save the values. Repeat the process for the Password secret.

The Cloud Template is fairly straight forward. The new user password will be assigned the secret.Blog_Password value, and the ssh_authorized_keys comes from secret.Blog_SSH_Key value.

inputs:
  username:
    title: username
    type: string
resources:
  web1:
    type: Cloud.Machine
    networks:
      - name: '${resource.AppNetwork.name}'
    properties:
      image: CentOS 8
      flavor: generic.small
      networks:
        - name: '${AppNetwork.name}'
          network: '${resource.AppNetwork.id}'
      remoteAccess:
        authentication: usernamePassword
        password: changeMe
        username: '${input.username}'
      cloudConfig: |
        #cloud-config
        chpasswd: { expire: False }
        ssh_pwauth: True
        users:
          - default
          - name: ${input.username}
            passwd: ${secret.Blog_Password}
            sudo: ['ALL=(ALL) NOPASSWD:ALL']
            groups: [wheel, sudo, admin]
            shell: '/bin/bash'
            lock_passwd:  false
            ssh_authorized_keys:
              - ${secret.Blog_SSH_Key}
        preserve_hostname:  false
        chpasswd:
          list: |
            ${input.username}:${secret.Blog_Password}
          expire:  False
        runcmd:
          - echo "disable_vmware_customization: false " >> /etc/cloud/cloud.cfg
          - sed -i 's/D \/tmp 1777 root root -/#D \/tmp 1777 root root -/g' /usr/lib/tmpfiles.d/tmp.conf
  AppNetwork:
    type: Cloud.Network
    properties: {}

Now a look at how the secret values are displayed on a deployed machine. Open the deployment, then click on the machine. Expand Cloud Config to view the secret values sent to the machine.

As you can see the values for the new user are encrypted, and do not match stored secret values (The user password is set to VMware1!). Good so far.

Now to see if the password and SSH key actually work. A quick SSH using the key should be sufficient.

Oops. Looks like the key didn’t work, but I was able to login using the password. Time for a bit of troubleshooting. Using elevated permissions (set in Cloud-Init), I take a look at the cloud-init config sent down to the machine.

#more /var/lib/cloud/instance/cloud-config.txt

Hmm, looks the key had a line return in it.

I’ll need to edit/update the Blog_SSH_Key secret. After finding my troublesome secret, I click Edit.

The previously stored value is not viewable, I can only update it.

The new value is viewable until I save it. I made sure this one didn’t have a line return in it. The changes are committed when I click Save.

Now to test the change on a newly deployed machine. I’ll use the same SSH command, with the exception of changing the IP address.

Success! I was able to log in using the key.

In this blog I explored a simple application using two vRA Cloud Secrets, troubleshooting, and updating a secret Value. The VMware developers did a great job. I’m sure the new feature will prove to be very valuable.

I’m not sure when this will get pushed down into vRA 8.x. Please contact your VMware team for more information.

Go forth and succeed.

One of the common use cases I see is having the ability to optionally add disks to a machine in vRealize Automation Cloud.

For example, one requester may just want a basic machine with just the OS disk, while another may want several to support SQL Server.

In this article I’ll show you how to add up to four additional disks using an undocumented vRA Cloud function. The other available functions are listed on this VMware documentation page.

Now down to details. What we need to do is create some property bindings for the optional disks, then attach them to the machine using ‘map_to_object’. The grey dashed lines indicate an implicit or property binding in the canvas. Additional information about this kind of bind is available at this VMware documentation page.

Four inputs are needed, one for each disk. Each disk that is NOT zero size will be created for the machine.

  Cloud_Machine_1:
    type: Cloud.Machine
    properties:
      name: '${input.hostname}'
      image: Windows 2019
      flavor: generic.medium
      attachedDisks: '${map_to_object(resource.Cloud_Volume_1[*].id + resource.Cloud_Volume_2[*].id + resource.Cloud_Volume_3[*].id + resource.Cloud_Volume_4[*].id, "source")}'

Here is the complete YAML for the blueprint.

formatVersion: 1
name: Optional disks
version: 1
inputs:
  hostname:
    type: string
    default: changeme
    description: Desired hostname
  password:
    type: string
    encrypted: true
    default: Password1234@$
    description: Desired password for the local administrator
  ipAddress:
    type: string
    default: 10.10.10.10
    description: Desired IP Address
  disk1Size:
    type: integer
    default: 5
    description: A SIZE of 0 will disable the disk and it will not be provisioned.
  disk2Size:
    type: integer
    default: 10
    description: A SIZE of 0 will disable the disk and it will not be provisioned.
  disk3Size:
    type: integer
    default: 15
    description: A SIZE of 0 will disable the disk and it will not be provisioned.
  disk4Size:
    type: integer
    default: 20
    description: A SIZE of 0 will disable the disk and it will not be provisioned.
resources:
  Cloud_Machine_1:
    type: Cloud.Machine
    properties:
      name: '${input.hostname}'
      image: Windows 2019
      flavor: generic.medium
      remoteAccess:
        authentication: usernamePassword
        username: Administrator
        password: '${input.password}'
      resourceGroupName: '${env.projectName}'
      attachedDisks: '${map_to_object(resource.Cloud_Volume_1[*].id + resource.Cloud_Volume_2[*].id + resource.Cloud_Volume_3[*].id + resource.Cloud_Volume_4[*].id, "source")}'
      networks:
        - network: '${resource.Cloud_Network_1.id}'
          assignment: static
          address: '${input.ipAddress}'
  Cloud_Volume_1:
    type: Cloud.Volume
    properties:
      count: '${input.disk1Size == 0 ? 0 : 1 }'
      capacityGb: '${input.disk1Size}'
  Cloud_Network_1:
    type: Cloud.Network
    properties:
      networkType: existing
      constraints:
        - tag: 'network:vsanready_vlan_14'
  Cloud_Volume_2:
    type: Cloud.Volume
    properties:
      count: '${input.disk2Size == 0 ? 0 : 1}'
      capacityGb: '${input.disk2Size}'
  Cloud_Volume_3:
    type: Cloud.Volume
    properties:
      count: '${input.disk3Size == 0 ? 0 : 1 }'
      capacityGb: '${input.disk3Size}'
  Cloud_Volume_4:
    type: Cloud.Volume
    properties:
      count: '${input.disk4Size == 0 ? 0 : 1}'
      capacityGb: '${input.disk4Size}'

Now to test it. I’ll deploy a machine with four additional disks. Here is the request form with the default disk sizes.

After deploying the machines, you may find the disks did not get added in order. This is known issue. The offshore developers told me ordered addition of disks is not supported at this point (July 2020). Here is a screen shot of the deployed machines. Notice the order, they are not the same as my request.

In mid July 2020 they released a new vRA Cloud version with additional data for the block-devices. At the time writing this article, the new properties were not included in the block-device model in the API documentation.

They are neatly stashed under customProperties.

    "customProperties": {
        "vm": "VirtualMachine:vm-880",
        "vcUuid": "b24faac3-b21c-4ee9-99f1-c5436d351ecb",
        "persistent": "true",
        "independent": "false",
        "provisionGB": "10",
        "diskPlacementRef": "Datastore:datastore-541",
        "provisioningType": "thin",
        "controllerUnitNumber": "1",
        "controllerKey": "1000",
        "providerUniqueIdentifier": "Hard disk 2"
    }

As you can see they provide the controller number (controllerKey), unit number (controllerUnitNumber), and the provider generated unique identifier (providerUniqueIdentifier).

The idea was to provide this information for those organizations wishing to reorder the disks or even move them to new disk controllers to support their various server deployments.

These additional properties may make into the next version of vRA 8. But who knows what makes the cut.

Until next time, stay safe and healthy.