Subscribe

RBAC - Clustered Data ONTAP

[ Edited ]

Hello All,

 

I am trying to create a RBAC Rule where in user should have a full admin access on a system manager level but have a readonly access on CLI. 

I tried to do the following but got that message, that same user can be a part of two different roles:

 

security> login create -user-or-group-name rbacv1 -application http -authmethod password -role admin
iceage::security> login create -user-or-group-name rbacv1 -application ontapi -authmethod password -role admin

iceage::security> login create -user-or-group-name rbacv1 -application ssh -authmethod password -role readonly

Error: User "rbacv1" is already defined with role "admin". Adding a login for this user with a different role (readonly) is not supported.

iceage::security>

 

Any Suggestations.

 

,Sheel

Re: RBAC - Clustered Data ONTAP

Hi Sheel, 

 

Did you try doing it from Oncommand System Manager itself ? As it is more easier and infact i am not a CLI fan ,  Please go through KB to find more information https://kb.netapp.com/index?page=content&id=1013627&pmv=print&impressions=false

 

OCSM2.png

Re: RBAC - Clustered Data ONTAP

Hi Sheel -

 

Despite the syntax of the command, which is somewhat confusing, you are mixing elements that are independent of each other.

 

In the "security login create" command you need to specify two elements at a minimum.  First is the access method (http, ssh, etc.) and second is the authentication method when a user tries access via that method.  These two elements are tied together in a pair and associated to the user, and obviously there can be multiple pairs of access/authentication created.

 

You can optionally specify a "role" which is tied only to the user, not the combination of user and access/authentication style.  The role lists what the user can do once they get access by any of the methods allowed.  And yes, both the documentation and the command syntax aren't explicitly clear that the role is tied only to the user [ well - technically the user and the SVM ].  For any given SVM a user can only have one role.  Once a user is granted access via authentication by any mechanism, then they get the rights identified in the single role associated to the user in that SVM.

 

One possible way to accomplish what you want might be to allow access with different roles via both the target SVM and the cluster itself.  You could grant needed access with default role "vsadmin" at the SVM level and then access to the Cluster at a "readonly" level via other means.

 

Based on your sample commands though I see you want to do this at the cluster level, given your choice of applications.  At that level only you can't limit "capability" based on mechanism used to access the cluster.  If you think about it this makes sense.  If you given someone full access, you given them full access.  Even if you could limit to readonly access via SSH, I just do the same thing I want via a ZAPI call and totally ignore your restriction on SSH such that the restriction doesn't accomplish anything.

 

You would need to move to multiple user names to accomplish this security difference.

 

Hope this helps!

 

 

Bob Greenwald