DNS & certificate requirements for vRealize Automation 8 multitenancy

Lately I have been in a few discussions related to multitenancy in vRealize Automation 8 and the related DNS and certificate requirements. In this post I describe how we can combine the vRA requirements with a user friendly URL to access the vRA portal.

DNS requirements

In earlier vRA versions the tenant ID was specified at the end of the vRA URL, something like vra.homelab.vmw/vcac/org/tenant01. Specifying the tenant at the end of the URL meant that there weren’t any special requirements for DNS, which made it quit simple. In vRA 8 however, the tenant URL uses the following schema .... Workspace One Access (WOA), formerly VMware Identity Manager (IDM), is no longer part of the vRA appliances instead separate WOA appliances are used in vRA 8. The combination of separate WOA appliances and the new URL schema implies the creation of specific DNS records when enabling multiitenancy.

Its important to thoroughly think and plan the tenants and associated URLs before starting the vRA deployment, tenants cannot be renamed nor removed once created. The only solution, currently, is redeploying the vRA environment.

For vRA 8 following DNS records are needed in a clustered multitenant environment:

• A type A record for each appliance and the WOA and vRA loadbalancers
• A type A record for each tenant pointing to the WOA loadbalancer IP address.
• A CNAME record for each tenant, except the master-tenant, pointing to the vRA loadbalancer FQDN.

Customers typically already have an idea on which URL they want for their vRA portal. Based on the discussions I recently had it seems to easiest to start from the URL customers have in mind and identify the associated DNS records needed by vRA based on this.

In our example we want to use the following:

• vRA portal URL: vportal.homelab.vmw
• URL for the main tenant: itservices.vportal.homelab.vmw
• URL for tenant A: tenant-A.vportal.homelab.vmw
• URL for tenant B: tenant-B.vportal.homelab.vmw

When we now look at how above URL’s match with the requirements of vRA:

• The vRA portal URL, vportal.homelab.vmw, implies:
  • The vRA loadbalancer Type A host record needs to be vportal.homelab.vmw and point to the vRA loadbalancer IP.
• The itservices.homelab.vmw URL for the main tenant implies:
  • The WOA master tenant alias needs to be itservices.
  • A Type A host record itservices.homelab.vmw pointing to the WOA loadbalancer IP.
• The tenant-A.homelab.vmw URL for tenant A implies:
  • A type A host record tenant-a.homelab.vmw pointing to the WOA loadbalancer IP.
  • A CNAME record tenant-a.vportal.homelab.vmw pointing to the vRA loadbalancer FQDN
• The tenant-B.homelab.vmw URL for tenant A implies:
  • A type A host record tenant-b.homelab.vmw pointing to the WOA loadbalancer IP.
  • A CNAME record tenant-b.vportal.homelab.vmw pointing to the vRA loadbalancer FQDN

In a standard WOA deployment a single default tenant, the master tenant, exists. When enabling multitenancy in a vRealize suite environment, a master tenant alias needs to be specified. This master tenant alias is linked to the provider/primary vRA tenant. The master tenant needs to be assigned to the cloud team itself as its the tenant from which Virtual Private Zones (VPZ) can be shared to other tenants.

The below table contains an overview of all the DNS records which are required in our example:

Certificate requirements

Now that we have all the required DNS records listed, we need to have a look at the requirements for the certificates. The certificates need to support the different tenant URLs etc.

The easiest solution is to use a wildcard certificates, a wildcard certificate eg. *.homelab.vmw supports the different URLs used by vRA. They make it also easy to add additional tenants on a later stage since the certificate doesn’t needs to be changed. The downside however is that wildcard certificates are typically seen as a security risk.

In case you cannot use a wildcard certificate in your environment then regular certificates need to be created and these require specific SAN records to be configured. The below table contains an overview of the different DNS name SAN records that need to be specified during certificate creation.