One of the cool things that UCS allows you to do is create a place where different users of different organizations can go to to configure their pools of resources. Its a common goal for many organizations to reduce duplication and allow agility and flexibility. A multi-tenant solution that has been talked about can actually become a reality with UCS in the form of Role Based Access Control (RBAC).
Let’s suppose that a local county has decided it wants to consolidate its IT infrastructure into its IT department as opposed to every department having its own IT instances. It can start off slowly, by say, starting with one or two organizations like the department of Superior Courts and the department of Executive Services.
Here’s how the main IT organization might configure RBAC for the Superior Courts and the Department of Executive Services.
1. Create suborganizations
Log in as admin and navigate to the Servers tab. From there you can expand the Service Profiles and see “root” and “Sub-Organizations”. Right click on “root” and add an organization:
2. Create Locale
A locale in UCSM is designed to reflect the location of a user in an organization. By default all users are at the ‘root’ level locale, but if we are creating sub-organizations, we want them to use their own stuff and not modify existing resources that exist at the root level, or with other organizations.
Navigate to the Admin Tab in navigation pane, filter by User Management, expand User Services and right click on Locales.
From here we can create a local named Superior_Court and bind it to the Superior_Court organization we created.
Next, to assign the organization, we just expand the Organizations menu and drag the Superior_Court into the pane on the right.
Clicking finish gives us our new locale bound to its sub organization.
3. Create a User for the Organization
Now let’s create a user called sc-admin that has all the rights in the Superior_Court local, but can’t change things in the root locale or any other locales.
On the navigation pane in the same place you were on the previous step, right click Locally Authenticated Users and select ‘Create User’.
The first fields are pretty self-explanatory. We created the user and password and left out some of the other information. The important part is that the locale is set to Superior_Court. This confines the powers of this user into Superior_Court. We can then select all the roles except the following:
– aaa: Authentication, Authorization, and Accounting. This can only be done in the root locale
– admin: this can only be given in the root locale
– operations: can only be given to root locale.
Now that sc-admin is created. Give him to your local friendly Superior Court tenant and let them have access to the system.
Now then… What can sc-admin do?
If you now log in as sc-admin, you can see that he can create service profiles, pools, and policies, but only in his superior_court suborg. If sc-admin tries to create a resource in the root organization, he is blocked from doing so because all of the options are greyed out:
Here’s what else he can do:
- He can create sub organizations within his own Sub-organization.
- He can create VLANs in the LAN and enable and disable network ports on the Fabric Interconnects. (because he was given network access… if you don’t want this take away the network privilege)
- He can create VSANs and disable and enable FC interfaces. (take away the storage privilege if you don’t want him to do this)
An interesting scenario I ran across is that if you remove a role from a user while that user is still logged in, it doesn’t seem to take effect until the user logs in later. For example, I disabled sc-admin’s network role and he was still able to create VLANs and turn ports off and on. When I logged him out and logged him back in again, the role acted how it should have.
One of the disadvantages of disabling the network role is that sc-admin can’t create VNIC Templates. This is something we might want to allow him to do in his own org. We can change this by creating a new role in the user management entitled Network_SP. For this role, we just check:
- Service Profile Network
- Service Profile Network-Policy
- Service Profile Qos
- Service Profile Qos Policy
Next, add this role into the sc-admin account (click on locally authenticated users and right click sc-admin and add a check to the Network_SP role we created)
Now sc-admin can create vNIC templates in his own sub org, but he isn’t allowed to create external VLANs and disable/enable ports on the Fabric Interconnect. For this to take affect, have sc-admin log out and log back in again after you apply the role.
You can do something very similar on the Storage tab in order to allow a suborg to create and modify its own vHBA Templates but not be able to disable FC ports on the Fabric Interconnects.
Once this is in place, you can repeat the operation for the department of Executive Services. As other departments join the consolidated data center their users are simply added to the locales and given roles.
Comments are closed.