Using multi-organization tenant configurations in
VMware Aria Automation

VMware Aria Automation
enables IT providers to set up multiple tenants, or organizations, within each deployment. Providers can set up multiple tenant organizations and allocate infrastructure within each deployment and also manage users for tenants.
In a
VMware Aria Automation
multi-organization configuration, providers can create multiple organizations, and each tenant organization manages its own projects, resources and deployments. While providers cannot manage tenant infrastructure remotely, they can log in to tenants and manage infrastructure within their tenants.
Multi-tenancy relies on coordination and configuration of three different VMware products as outlined below:
  • Workspace ONE Access
    - This product provides the infrastructure support for multi-tenancy and the Active Directory domain connections that provide user and group management within tenant organizations.
  • VMware Aria Suite Lifecycle
    - This product supports the creation and configuration of tenants for supported products, such as
    VMware Aria Automation
    . In addition, it provides some certificate management capabilities.
  • VMware Aria Automation
    - Providers and users log in to
    VMware Aria Automation
    to access tenants in which they create and manage deployments.
When configuring multi-tenancy, users should be familiar with all three of these products and their associated documentation.
For more information about working VMware Aria Suite Lifecycle and Workspace ONE Access, see the following:
Administrators with
VMware Aria Suite Lifecycle
privileges create and manage tenants using the
VMware Aria Suite Lifecycle
tenants page located under the
Identity and Tenant Management
service. Tenants are constructed by using an Active Directory IWA or LDAP connection. They are supported by the associated
Workspace ONE Access
instance that is required for
VMware Aria Automation
deployments.
When configuring multi-tenancy, you start with a base, or master tenant. This tenant is the default tenant that is created when the underlying
Workspace ONE Access
application is deployed. Other tenants, known as sub-tenants, can be based upon the master tenant.
VMware Aria Automation
currently supports up to 20 tenant organizations with the standard three node deployment.
Before enabling
VMware Aria Automation
for multi-tenancy, you must first install the application in a single organization configuration, and then use
VMware Aria Suite Lifecycle
to set up a multi-organization configuration. A
Workspace ONE Access
deployment supports the management of tenants and the associated Active Directory domain connections.
When you initially set up multi-tenancy, a provider administrator is designated in
VMware Aria Suite Lifecycle
. You can change this designation or add administrators later if desired. Under multi-organization configurations,
VMware Aria Automation
users and groups are managed primarily through
Workspace ONE Access
.
After organizations are created, authorized users can log in to their applications to create or work with projects and resources and create deployments. Administrators can manage user roles in
VMware Aria Automation
.

Setting up for a multi-organization configuration

You can enable a multi-organization deployment after completing a
VMware Aria Automation
installation. When setting up a multi-organization configuration, you must configure your external
Workspace ONE Access
for multi-tenancy use and then use Lifecycle manager to create and configure tenants. This applies to both new and existing deployments. As an initial step to setting up tenants, you must use
VMware Aria Suite Lifecycle
to set an alias for the master tenant that was created by default on
Workspace ONE Access
. Sub-tenants that you create based on this master tenant inherit the Active Directory domain configurations from this master tenant.
In Lifecycle Manager, you assign tenants to a product, such as
VMware Aria Automation
, and to a specific environment. When setting up a tenant, you must also designate a tenant administrator. By default, multi-tenancy is enabled based on tenant hostname. Users can elect to manually configure tenant name by DNS name. During this procedure you must set several flags to support multi-tenancy, and you must configure the load balancer as well.
If you use a clustered instance, both the
Workspace ONE Access
and
VMware Aria Automation
tenant based hostnames will point to the load balancer.
If your clustered
VMware Aria Automation
and
Workspace ONE Access
load balancers do not use wildcard certificates, then users must add tenant hostnames as SAN entries on the certificates. for every new tenant that is created.
You cannot delete tenants in
VMware Aria Automation
or in
VMware Aria Suite Lifecycle
. If you need to add tenants to an existing multi-tenancy deployment, you can do this using
VMware Aria Suite Lifecycle
, but it will require downtime of three to four hours.
Refer to the documentation links at the beginning of this topic for more information about using
VMware Aria Suite Lifecycle
Workspace ONE Access
.

Hostnames and multi-tenancy

In prior versions of
VMware Aria Automation
, users accessed tenants with URLs that were based on directory path. In the current multi-tenancy implementation, users access tenants based on hostname.
Also, the hostname format that
VMware Aria Automation
users will use to access tenants differs from the format that is used to access tenants within
Workspace ONE Access
. For example, a valid hostname would look like the following:
tenant1.example
.eng.vmware.com
as opposed to
vidm-node1.eng.vmware.com
.

Multi-tenancy and certificates

You must create certificates for all components involved in a multi-organization configuration. You will need one or more certificates for
Workspace ONE Access
,
VMware Aria Suite Lifecycle
, and
VMware Aria Automation
, depending on whether you are using a single node configuration or a clustered configuration.
When configuring certificates, you can use either wildcard with the SAN names or dedicated names. Using wild cards will simplify certificate management somewhat as certificates must be updated whenever you add new tenants. If your
VMware Aria Automation
and
Workspace ONE Access
load balancer do not use wildcard certificates, then you must add tenant hostnames as SAN entries on the certificates for every new tenant that is created. Also, if you use SAN, certificates must be updated manually if you add or delete hosts or change a hostname. You must also update DNS entries for tenants.
Note that
VMware Aria Suite Lifecycle
does not create separate certificates for each tenant. Instead it creates a single certificate with each tenant hostname listed. For basic configurations, the tenant's CNAME uses the following format:
tenantname
.
vrahostname.domain
. For high availability configurations, the name uses the following format:
tenantname
.
vraLBhostname
.domain.
If you are using a clustered
Workspace ONE Access
configuration, note that Lifecycle Manager cannot update the load balancer certificate, so you must update it manually. Also, if you need to re-register products or services that are external to
VMware Aria Suite Lifecycle
, this is a manual process.