Cisco ACI role based access control (RBAC)

July 14th 2018

ACI Role Based Access Control (RBAC)

We want to give some insight into the Role Based Access Control (RBAC) functionality. Cisco ACI is designed to be multi-tenancy which means being able to host a number of different customers or business units (with different networking requirements and business practices) on a single fabric.

We have seen that even within a single Enterprise, different business units operate with different levels of agility with often contrasting business requirements. For example; some teams may be embracing automation with latest technologies whilst other teams may consider stability as a priority. Granted, these two working practices are not mutually exclusive but more traditional departments may consider them to be. In modern networks, with automation as ubiquitous as it is, businesses want to move away from traditional network task provisioning. E.g waiting five days for a firewall rule to be added or another five days for a new VLAN to be provisioned. As different business units (potentially tenants) look to automate provisioning, an emphasis is placed on RBAC to reduce the configuration error blast radius.

From an ACI perspective, multitenancy environments work best when full control for a tenant is handed over to a business unit. This allows them to operate under their own business processes with various levels of agility and their own change control windows. If full control is handed over to the business unit, then it’s imperative that the administrative change domain (and fault domain) is scoped appropriately.

This begs the question; How is the configuration of Tenant A isolated from the configuration of Tenant B? ACI facilitates RBAC by leveraging a few core APIC concepts:

RBAC core components

Users: These can be stored locally on the APIC or read from an external repository.

Privileges: Predefined sets of object model classes within the MIT (Management Information Tree) which can be accessed. For example, there is a default Privilege called ‘tenant-security’. This Privilege controls access to contract related configurations. It is not possible to create your own privileges, only to reuse existing ‘out of the box’ privileges. Details of all of the predefined privileges are documented in the APIC documentation.

Roles: A collection of privileges. The role does not itself specify the type of access (read only or read/write) to each of the managed objects. ACI provides a number of predefined roles which could be assigned but it’s more likely that custom roles will need to be created to meet specific requirements.

In the screenshot, we can see the default roles and how a number of different privileges are assigned.

 

Access rights (privilege types): This determines a level of access (read only or read/write) that can be given to a role.

Security domains: This is a type of tag that can be applied to a section of the MIT. The concept is best described by Cisco as ‘an intermediate entity between tenants and users’.

These five elements above need to be bound together to control who can access what and at which privilege. A user needs to be assigned to a security-domain (default or custom) and assigned a role (default or custom) along with the role privilege type. At this point, it’s worth mentioning that RBAC doesn’t apply just to GUI based access but it also enforces access control to the API.

 

In the diagram above, we can see how the security domain acts at the attachment point between the user and the tenant.

 

Considerations

In current APIC software releases, security domains can only be applied at a tenant level.  There is no way to apply a security domain tag to any child class of the tenant (such as Application Profile of EPG). Therefore, if two business units shared a Tenant, both business units would have full control of each other’s configuration. It’s likely that this will drive tenant design and encourage providing dedicated tenants for each business unit.

As the APIC Security Configuration Guide highlights, one challenge is how connectivity to bare metal severs is configured. Tenant administrators will not by default have access to the infra domain which is required to configure interfaces of leaf switches. Many organizations would be reluctant to provide users with fabric admin address for very good reasons. One way around this could be to be to blanket configure certain switch interfaces in advance ready for physical servers to be cabled to. This would prevent the tenant administrators from having to invoke support from fabric admins.

Although this may appear to be a restriction at first, there are a number of different ways to handle the provisioning of physical connectivity via automation tasks.

External authentication

Most organizations will want to incorporate an external authentication server with their RBAC solution to provide for AAA support. Cisco supports this method with the use of AV pairs configured on the authentication server e.g. Cisco ISE. The required AV pair format is as follows:

shell:domains =

ACI_Security_Domain_1/ACI_Write_Role_1|ACI_Write_Role_2|ACI_Write_Role_3/ACI_Read_Role_1|ACI_Read_Role_2

ACI_Security_Domain_2/ACI_Write_Role_1/ACI_Read_Role_1|ACI_Read_Role_2|ACI_Read_Role_3

"shell:domains="   -  This element is required so that ACI reads the string correctly. This must always prepend the shell string.

The first focus point for the examples below is the positioning of the ‘/’ character as this is the separator between the security domain, write and read sections of the AV pair string. This means that any string including two consecutive forward slashes, E.g. ACI_Security_Domain_1//admin, assigns the role to the security domain with read privileges only. The second focus point is the positioning of the '|' character which indicates multiple roles with the same privilege type (e.g. read only or read-write).

Example AV pairs:

ACI_Security_Domain_1//admin - Grants admin read only access to the tenants in this security domain.

ACI_Security_Domain_2/admin - Grants admin write access to the tenants in this security domain.

ACI_Security_Domain_3/vmm-admin/fabric-admin|nw-svc-params - Grants write access with the 'vmm-admin' role and read-only access to both the 'fabric-admin' role and the 'nw-svc-params' role.

 

Additional features

ACI has one additional trick up it's sleeve to offer further flexibility for access control; a concept called 'Custom RBAC rules'. Rather than performing all access control based on security domains, Custom RBAC can provide explicit access to specific objects outside of the assigned security. Based on the earlier example, Dave Smith had been assigned to the 'engineering-domain' security domain which would have provided him access to the 'engineering' tenant. This is represented by the 'Implicit Rules'.

 

However, to provide Dave Smith with access to an object outside of his assigned security domain, an 'Explicit Rule' can be created to bind the distinguished name of an object (e.g. uni/tn-sales). This would allow the user to access the 'Sales' tenant which would be assigned to a different security domain. Explicit rules are essentially cross security domain exceptions.

 

An interesting authentication feature that is supported is the concept of dynamically assigning roles based on time or explicit request. This could be useful in extremely security conscious environments where access control is a priority. In this case, write privileges could be assigned dynamically when a change window commences.

Additionally, as of release 3.1, the APIC will actively throttle the number of password-based authentication requests once a certain threshold is breached. Although this doesn’t sound like an issue for GUI users, this is an issue once levels of automation are increased and the number of REST calls to the API increase dramatically. The recommended solution is to use certificate-based authentication for access to the API. Not only does this mitigate the authentication throttling and improve security, it also reduces the time for automation tasks to complete. We’ve seen certificate-based authentication drastically reduce the time required to provision full tenant structures via Ansible so strongly recommend this.

In conclusion, RBAC could easily be considered as a simple task but when tenant design and automation strategies are taken into consideration, there is more to it than first meets the eye.

BestPath.

BACK TO BLOG

More