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.
- Configuration Flexibility — Users with access as defined by the
Tenant-Adminrole (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.
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:
- Creates two VRF contexts for the cloud in the particular tenant. One is assigned data-plane traffic, and the other control-plane (management) traffic.
- Creates the first SE group for the cloud in this tenant (it will be named
- 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.
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
adminuser to create the cloud within the tenant. This example has been given merely to show that such a courtesy may be offered.
Figure 4 displays the next step in cloud creation. From this point forward, cloud creation can proceed as normal.
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.
Figure 6 shows how the
appl1 user can opt to create a Linux server cloud with the
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.