Multi-Tenancy and Access Control

A10 Control is inherently multi-tenant, meaning it can segregate management across different teams or customer groups securely. In a multi-tenant setup, different administrators may have authority over different subsets of devices or partitions, without visibility into others. This is achieved through a combination of a hierarchical administrative scope model and a robust Role-Based Access Control (RBAC) system.

This section explains how A10 Control defines administrative scopes (or personas) and how roles and permissions are structured.

Tenant Hierarchy: Organizations and Org Units

The primary structure for multi-tenancy in A10 Control is a two-level hierarchy:

• Organization: This is the top-level tenant account (analogous to a company or a major account). An Organization contains one or more Org Units. Each Organization has its own admin users, its own pool of devices and resources, and is isolated from other Organizations.

  In a self-managed deployment, a controller (super-admin) user can create multiple separate Organization accounts – for example, a managed service provider might host an Organization for each customer. In a SaaS deployment, your enterprise likely corresponds to one Organization provided by A10.

• Org Unit: These are sub-tenants or subdivisions under an Organization. Org Units are optional and can be used to delegate administration to smaller groups or projects within an Organization. For instance, if Organization “Acme Corp” has two departments using A10 devices, each department could be an Org Unit with its own Org Unit Admin managing its applications.

  Org Units allow internal multi-tenancy so that each team’s activities are isolated. An Org Unit has its own set of application services (like its own ADC instances or its own DDoS policies) and its Org Unit Admin cannot affect other Org Units.

Partition Admin Role and Logical Partitions

There are two types of partitions that can be created to segment ACOS device, Layer 3 Virtualization (L3V) partitions are network-enabled partitions. and Service partitions (SvP) are non-network-enabled partitions. For more information about partition, see Application Delivery Partitions Guide.

The Service Partition can be created within the actual Shared Partition of a Thunder device. Multiple Service Partitions can be created within a Shared Partition. Some application services run on these Service Partitions and some can still remain within the Shared Partition.

After a Thunder device is registered in A10 Control, these Service Partitions must be mapped to Logical Partitions. The Logical Partitions become resources that can be accessed by users with Partition Admin role.