RBAC for Fabric Access

[Claudia de Luna]

Scenario:

An Organization has an ACI fabric in their data center.  Each BU in the organization can purchase their own leaf switches based on their requirements.  Each BU has their own tenant, say Sales and Finance.

Operationally, the Organization would like to restrict management of the Sales purchased leafs to the admins of the Sales Tenant etc. Sales wants the autonomy of configuring the interfaces and other supporting Fabric Access constructs themselves.  The Organization wants to ensure that Sales cannot impact Finance equipment etc.

Can this be done in ACI?  Configuration Zones seem like a good start but not sure how to tie those to roles and security domains.

Basically the Sales Tenant admin should have access to the Sales Tenant itself and Fabric Access Policies that pertain to say their Configuration Zone which has the Leafs they purchased. 

They should only be able to define switch Profiles for those specific leafs, etc.

When configuring static path bindings etc. they should only have access to interfaces on those leafs etc..

Thanks for any guidance!

[gmonroy]

Hello Claudia,

Based on my understanding of RBAC and how it is implemented within ACI, the high level answer to your idea above is that it is not easily possible today. That is, the majority of RBAC configuration separation is based on the DNs of the object you are looking to allow access to.

To be specific, security domains are tied to a tenant which is essentially giving that user access to anything under the branch of your tenant. For example, a user with a security domain tied to TenantB has access to the DN of TenantB (uni/tn-TenantB) and all that could potentially be below it such as:

• Bridge Domains: uni/tn-TenantB/BD-TenantBBridgeDomain
• EPGs: uni/tn-TenantB/ap-myApp/epg-ActiveDirectoryEPG

The other method of slicing of the MIT, rather manually, is with the usage of RBAC rules (Admin > AAA > Security Management > RBAC Rules). That is, you can defined explicit DNs(branches of the MIT) and give access to everything under that branch to some Domain, and subsequently users of that domain.

Now if you were to take that idea and try to apply it to Access Policies, you would need to understand what DN conventions are in place (if any) when isolating a node ID group A from Node ID group B (or in your scenario, Sales Node IDs, vs Finance Node IDs). Looking at an example of a switch profile, the DN is solely built upon the name of the switch profile and can potentially make no reference to the node ID:

infraNodeP: uni/infra/nprof-Leaf_Prof_name

With the above knowledge, it can be seen that enforcing RBAC rules on a per node basis does not come easily unless there was some DC admin who would pre-provision the naming convention per node group, and then go through the motions of slicing up each specifically named branch per security domain.

I didn't go through Static bindings or other access policies, but the method for determining its feasibility is essentially the same as the above. Also, I don't see any method of tying a Configuration Zone to a Security Domain to simplify the above request.

Bonus: Here is a diagram that was designed to highlight this aspect of giving branch access per security domain with the user of explicit RBAC Rules.

Hope this helps.

-Gabriel

[goranje]

Hi Claudia, gmonroy,
I have to configure similar scenario as you describe.
Did you manage to configure RBAC for parts of fabric access per user?
I noticed that this is a post from 3 years ago.
Maybe you have some new ideas or useful configuration documentation to share?

Best regards,