The APIC provides access according to a user’s role through role-based access control (RBAC). An Cisco Application Centric Infrastructure (ACI) 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 ACI fabric 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 Application Policy Infrastructure Controller (APIC) 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 ACI MIT 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. For example,
an administrator could assign the “solar” domain tag to the tenant named solar. Within the MIT, only certain objects can be
tagged as security domains. For example, a tenant can be tagged as a security domain but objects within a tenant cannot.
Security Domain password strength parameters can be configured by creating Custom Conditions or by selecting Any Three Conditions that are provided.
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 ACI 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
For read operations to the managed objects that a user's credentials do not allow, a "DN/Class Not Found" error is returned,
not "DN/Class Unauthorized to read." For write operations to a managed object that a user's credentials do not allow, an HTTP
401 Unauthorized error is returned. In the GUI, actions that a user's credentials do not allow, either they are not presented,
or they are grayed out.
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)
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.
If a virtual machine management (VMM) domain is tagged as a security
domain, the users contained in the security domain can access the
correspondingly tagged VMM domain. For example, if a tenant named solar is
tagged with the security domain called sun and a VMM domain is also tagged with
the security domain called sun, then users in the solar tenant can access the
VMM domain according to their access rights.