Tenant-Scoped Clouds

For additional configuration flexibility and isolation as well as delegation of ADC administration, as of release 17.2.4, Avi Vantage supports the creation of a cloud inside a tenant. Referred to as tenant-scoped clouds, the feature is currently restricted to AWS, Azure, Linux Server Clouds, NSX-T, and no-orchestrator clouds. Attempts to choose other cloud types result in an error code.

Refer to Orchestrator Access Modes for more information on no-orchestrator (no-access clouds), in which adding, removing, or modifying properties of a Service Engine requires an administrator’s manual intervention.

Features

  • Configuration Flexibility — Users with access as defined by the Tenant-Admin role (see Figure 1 below) can create/read/update/delete (CRUD) cloud infrastructure (VRF contexts, SE groups, and SEs) within their very own tenant, i.e., the one to which the cloud is scoped. In addition, tenant administrators can access and use the infrastructure of clouds in the admin tenant, based on tenant settings, as before. That is to say, if infrastructure in an admin-tenant cloud is configured in provider mode, tenant administrators can use it. Their use of it is in addition to, and independent of any tenant-scoped clouds under their direct control.
Access rights assigned by default to the Tenant-Admin role Figure 1. Access rights assigned by default to the Tenant-Admin role

What is provider mode? It is a configuration in which Service Engines are shared across tenants. In provider mode all the cloud’s network resources remain in the admin tenant and cannot be moved. To configure VRF contexts and move port groups into them, the Avi Vantage user must have write privileges for the admin tenant.

  • Isolation — The tenant-scoped cloud and its associated objects (i.e., VRF context, SEs, SE groups) are only visible in the cloud’s tenant. They are not be visible in other tenants or in the admin tenant.
  • Administration — The admin user is authorized and responsible to perform the highest-level configuration operations, such as user creation and authorization, tenant creation, and all infrastructure associated with the admin tenant. However, the admin user may — and likely prefers to — delegate to tenant administrators the creation of clouds scoped to their respective tenants.

When creating a tenant-scoped cloud, Avi Vantage automatically:

  1. Creates two VRF contexts for the cloud in the particular tenant. One is assigned data-plane traffic, and the other control-plane (management) traffic.
  2. Creates the first SE group for the cloud in this tenant (it will be named Default-Group)
  3. Changes default permissions to enable the user having the Tenant-Admin role to create and manage tenant-scoped clouds and associated objects.

Avi UI Tenant-Scoped Cloud Creation

Figure 2 shows the admin user has logged in, has clicked on the icon in the top right of the toolbar to show the complete list of tenants defined, and has selected app_tenant_1 from that list. The administrator’s intent is to switch context into that tenant.

admin user switches context to app_tenant_1 Figure 2. The admin user switches context to app_tenant_1 by clicking the green **Done** button.


In Figure 3, the new tenant context is evidenced by the text admin(app_tenant_1) to the left of the icon in the top right of the toolbar. Note, it is still the admin user who is logged in; only the tenant context has changed.

Having navigated to Infrastucture > Clouds, the admin user has clicked on the green Create button. A subsequent click on the Microsoft Azure button indicates the user intends to create the descriptively named cloud admin-created-azure-cloud-for-tenant-1 on behalf of its users.

Note: It is not necessary for the admin user to create the cloud within the tenant. This example has been given merely to show that such a courtesy may be offered.

Admin user creating an Azure cloud in and for app_tenant_1 Figure 3. Admin user creating an Azure cloud in and for app_tenant_1

Figure 4 displays the next step in cloud creation. From this point forward, cloud creation can proceed as normal.

Admin user continues the Azure cloud setup Figure 4. Admin user continues the Azure cloud setup

What follows is the more typical scenario. User appl1, the tenant administrator of app_tenant_1 has logged in. As expected, when appl1 clicks on the icon in the upper right-hand corner of the screen, no other tenants are listed. Being restricted to the one tenant is what is normally desired.

appl1, the administrator of app_tenant_1, is restricted to that tenant Figure 5. appl1, the administrator of app_tenant_1, is restricted to that tenant


Figure 6 shows how the appl1 user can opt to create a Linux server cloud with the app_tenant_1 tenant.

The app_tenant_1 administrator chooses to create an LSC cloud within the tenant Figure 6. The app_tenant_1 administrator chooses to create an LSC cloud within the tenant


As before, the steps to creating a cloud are no different from clouds that are not tenant-scoped. It all depends on the tenant context of the user.

The app_tenant_1 administrator continues LSC setup Figure 7. The app_tenant_1 administrator continues LSC setup