A restricted security domain allows a fabric administrator to prevent a group of users, such as Tenant A, from viewing or modifying any objects created by a group of users in a different security domain, such as Tenant B, when users in both groups have the same assigned privileges. For example, a tenant administrator in Tenant A's restricted security domain will not be able to see policies, profiles, or users configured in Tenant B's security domain. Unless Tenant B's security domain is also restricted, Tenant B will be able to see policies, profiles, or users configured in Tenant A. Note that a user will always have read-only visibility to system-created configurations for which the user has proper privileges.

For example, consider a user in a restricted security domain is associated to Tenant A. Tenant A includes two application profiles, application profile 1 created by the user and application profile 2 created by an administrator. The user can view only application profile 1 although application profile 2 is also with the same tenant. When a user is in a restricted security domain, even profiles created by administrators are not visible.

In the above example, an unrestricted user (user not in a restricted security domain), can view both, application profile 1 and application profile 2, although application profile 2 was created by another user (administrator).

The Cloud Application Policy Infrastructure Controller (cAPIC) provides access according to a user’s role through role-based access control (RBAC). A fabric user is associated with the following:

• A set of roles

• For each role, a privilege type: no access, read-only, or read-write

• One or more security domain tags that identify the portions of the management information tree (MIT) that a user can access

The Cloud APIC manages access privileges at the managed object (MO) level. A privilege is an MO that enables or restricts access to a particular function within the system. For example, fabric-equipment is a privilege bit. This bit is set by the cAPIC on all objects that correspond to equipment in the physical fabric.

A role is a collection of privilege bits. For example, because an “admin” role is configured with privilege bits for “fabric-equipment” and “tenant-security,” the “admin” role has access to all objects that correspond to equipment of the fabric and tenant security.

A security domain is a tag associated with a certain subtree in the cAPIC object hierarchy. For example, the default tenant “common” has a domain tag common. Similarly, the special domain tag all includes the entire MIT object tree. An administrator can assign custom domain tags to the MIT object hierarchy.

Creating a user and assigning a role to that user does not enable access rights. It is necessary to also assign the user to one or more security domains. By default, the cAPIC fabric includes two special pre-created domains:

• All—allows access to the entire MIT

• Infra—allows access to fabric infrastructure objects/subtrees, such as fabric access policies

Cisco Cloud APIC supports the following AAA roles and privileges:

Custom privileges can be assigned to any MO Class. Twenty-two custom privileges are displayed in the Cisco Cloud APIC GUI. If one of these custom privileges is assigned to any class, that MO’s access will include the newly added custom privilege. One custom privilege can be associated with one or more MO classes.

Note	Although custom privileges are displayed by the Cisco Cloud APIC GUI, they are currently not supported.

A set of predefined managed object classes can be associated with domains. These classes should not have overlapping containment. Examples of classes that support domain association are as follows:

• Layer 2 and Layer 3 network managed objects

• Network profiles (such as physical, Layer 2, Layer 3, management)

• QoS policies

When an object that can be associated with a domain is created, the user must assign domain(s) to the object within the limits of the user's access rights. Domain assignment can be modified at any time.

RBAC rules selectively expose resources (such as, application profiles, EPGs, contracts) to users that are otherwise inaccessible because they are in a different security domain. An RBAC rule comprises two parts: the distinguished name (DN) that locates the object to be accessed and the name of the security domain that contains the user who will access the object.

There are two types of RBAC rules:

• Implicit—a user inherits a rule or permission based on RBAC hierarchy

• Explicit—a rule is directly assigned to the user based on certain policies

Both restricted and unrestricted security domains are supported.

Note

While an RBAC rule exposes an object to a user in a different part of the management information tree, it is not possible to use the CLI to navigate to such an object by traversing the structure of the tree. However, as long as the user knows the DN of the object included in the RBAC rule, the user can use the CLI to locate it via an MO find command.

The following are the guidelines and restrictions for the users of restricted domains:

• If a user from one security domain is assigned another security domain, the user gets access to the configurations associated with the new domain.

• A user can be part of one or more security domains which are marked “restricted”​.

• Restricted domain users have read-only access to system created configurations. ​

• For a user with multiple security domains, the combined length of all security domains cannot exceed 1024 characters. If the length exceeds 1024, the user will have policy creation issues.

• Restricted domain on the Cloud APIC is not supported on the cloud resources. This means, a user of one restricted domain will be able to see cloud resources created by a user of another restricted domain.