If you’re in a company that uses Nexus 5Ks to run both LAN and SAN, and for some strange reason your SAN Administrator wants access to the 5Ks for zoning, just deny it. Okay, okay, I guess that won’t fly, so let’s configure role-based access control (RBAC) to lock down what the SAN Administrator has access to.
Good thing about Nexus 5K is there is a built-in role called san-admin that we can use for this purpose. Let’s take a look at the role privileges:
N5K-2# sh role name san-admin
Role: san-admin
Description: Predefined system role for san administrators. This role
cannot be modified.
vsan policy: permit(default)
Vlan policy: permit(default)
Interface policy: permit(default)
Vrf policy: permit(default)
-------------------------------------------------------------------
Rule Perm Type Scope Entity
-------------------------------------------------------------------
27 permit read
26 permit read-write feature fcdomain
25 permit read-write feature rdl
24 permit read-write feature trunk
23 permit read-write feature fcmgmt
22 permit read-write feature fcfe
21 permit read-write feature port-track
20 permit read-write feature fcoe
19 permit read-write feature port-security
18 permit read-write feature copy
17 permit read-write feature rmon
16 permit read-write feature rscn
15 permit read-write feature fspf
14 permit read-write feature fdmi
13 permit read-write feature fcsp
12 permit read-write feature fcns
11 permit read-write feature span
10 permit read-write feature zone
9 permit read-write feature wwnm
8 permit read-write feature vsan
7 permit read-write feature vsanIfvsan
6 permit read-write feature fabric-binding
5 permit read-write feature interface
4 permit read-write feature trapRegEntry
3 permit read-write feature snmpTargetAddrEntry
2 permit read-write feature snmpTargetParamsEntry
1 permit read-write feature snmp
If you noticed at the top, full privileges are included in this profile for adding/modifying/deleting interfaces, VLANs and VRFs. Not cool.
Vlan policy: permit(default)
Interface policy: permit(default)
Vrf policy: permit(default)
Additionally, notice the privilege to configure device aliases is missing (yikes!). Needless to say, we will likely want to create a new role with some minor modifications.
Notice the “features” that are attached to the san-admin role. If we want to find out exactly what is included in these features, run this command:
show role feature name X
Here’s an example:
N5K-2# show role feature name zone
zone (Zone related commands)
show zone *
config t ; zone *
zone *
clear zone *
debug zone *
show zoneset *
config t ; zoneset *
zoneset *
clear zoneset *
debug zoneset *
show zone-attribute-group *
config t ; zone-attribute-group *
zone-attribute-group *
clear zone-attribute-group *
debug zone-attribute-group *
show fcalias *
config t ; fcalias *
fcalias *
clear fcalias *
debug fcalias *
Now to build the new role:
role name custom-san-admin
description Customized SAN Admin Role
rule 20 permit read
rule 19 permit command debug device-alias *
rule 18 permit command clear device-alias *
rule 17 permit command config t ; device-alias *
rule 16 permit read-write feature zone
rule 15 permit read-write feature wwnm
rule 14 permit read-write feature vsanIfvsan
rule 13 permit read-write feature vsan
rule 12 permit read feature snmp
rule 11 permit read-write feature trunk
rule 10 permit read-write feature rscn
rule 9 permit read-write feature rdl
rule 8 permit read-write feature ping
rule 7 permit read-write feature interface
rule 6 permit read-write feature fspf
rule 5 permit read-write feature fdmi
rule 4 permit read-write feature fcmgmt
rule 3 permit read-write feature fcfe
rule 2 permit read-write feature fcdomain
rule 1 permit read-write feature copy
vlan policy deny
interface policy deny
permit interface fc1/23-32
vrf policy deny
Verify the configuration:
N5K-1# show role name custom-san-admin
Role: custom-san-admin
Description: Customized SAN Admin Role
vsan policy: permit(default)
Vlan policy: deny
Permitted vlans: none
Interface policy: deny
fc1/23-32
Vrf policy: deny
Permitted vrfs:
-------------------------------------------------------------------
Rule Perm Type Scope Entity
-------------------------------------------------------------------
20 permit read
19 permit command debug device-alias *
18 permit command clear device-alias *
17 permit command config t ; device-alias *
16 permit read-write feature zone
15 permit read-write feature wwnm
14 permit read-write feature vsanIfvsan
13 permit read-write feature vsan
12 permit read feature snmp
11 permit read-write feature trunk
10 permit read-write feature rscn
9 permit read-write feature rdl
8 permit read-write feature ping
7 permit read-write feature interface
6 permit read-write feature fspf
5 permit read-write feature fdmi
4 permit read-write feature fcmgmt
3 permit read-write feature fcfe
2 permit read-write feature fcdomain
1 permit read-write feature copy
If you’re not using AAA, other than creating a local user attached to the custom-san-admin role, you’re all done. If you’re using AAA with something like Cisco ACS TACACS+, proceed below.
Assuming you’re already connected to ACS, configure AAA, make sure authorization is set to local (this will only show up in a “show run all”).
aaa authentication login default group ACS
aaa authentication login console group ACS
aaa accounting default group ACS
aaa authentication login error-enable
aaa authorization commands default local
aaa authorization config-commands default local
Assuming ACS is already in production, we just need to add a new shell profile.
Attribute: cisco-av-pair
Requirement: Mandatory
Value: shell:roles*”custom-san-admin”
And corresponding authorization policy:
You should now be able to login with the restricted custom-san-admin role. Verify:
N5K-1# sh user-account tester
user:tester
roles:custom-san-admin
account created through REMOTE authentication
Credentials such as ssh server key will be cached temporarily only for this user account
Local login not possible
Resources:
http://jeremywaldrop.wordpress.com/2012/10/22/nexus-5500-san-admin-rbac/
Thanks, Jeremy!
