3 Replies Latest reply on Aug 17, 2005 7:50 AM by Reese Williams

    RBAC Implementations - need feedback

      Hi - We are in the process of rolling out 6.3 and just finished training for our Windows and Unix/Linux admin teams within the last few weeks. While our training sessions were conducted on a limited set of "test/training" servers, management is now concerned that our environment is at more risk since an admin could deploy a change "with a click of a button" to hundreds of servers...


      Isn't that one of the reasons we bought BladeLogic? Note that all our admins have root (or administrator) access currently.


      So I'm wondering if this perceived risk is something that other organizations have faced in the initial implementation and adoption and how you have addressed it.


      I have taken the approach to leave the authorization details aside for the moment and define tasks that we currently do in our Engineering and Operations roles to work on identifying BladeLogic process and procedures around those tasks. This seems to be taking a productive course. But my major concern is slowing down the adoption process and loosing the momentum we gained through training since we are limiting access to All Servers.


      We currently have 4 roles - Windows OPs and Eng and Unix Ops and Eng. All have full authorizations assigned for their particular platform. All "Released" Eng Components, Jobs and Depot folders are shared to their Ops counterpart. This may or may not change..


      Any feedback you can share on your implementation would be appreciated.


      Thanks, Rebecca

        • 1. Re: RBAC Implementations - need feedback

          We resolved this issue with our auditors by demonstrating the increased logging and auditability. People have the same ability to blow things up "with the push of a button" without using the tool (as you have stated). But, now at least the tool logs/records the actions people take and provide a history and reporting capability.


          Your staff is going to be no less responsible in their behaviors just because they have a new tool. And, now management can have warm fuzzies because they can have greater visibility into what's been done in the environment.


          It's all a matter of managing perceptions.


          • 2. Re: RBAC Implementations - need feedback

            Thanks for the perspective. I agree. Subsequent discussions have remained focused more on process and procedure and less on authorizations. I've mentioned the fact that we gain more logging (both for the auditors as well as for our own use - reporting and root cause when something goes wrong), but I took the opportunity to mention it again after reading your posting.


            Thanks again, Rebecca

            • 3. Re: RBAC Implementations - need feedback



              A couple of ideas might work:


              1) Can you remove or limit root access to other types of users, such as developers, etc...do they have to be mapped to root? This at least limits the users who can execute something in parallel as root.


              2) Maybe you can position it as "hey, we are limiting the resources that are less skilled and enabling the resources (sysadmins) who are more skilled. Wouldn't you want them to be more productive?" Or... "How likely is it that a skilled SA is going to do something undesirable?" (ok don't ask that one)


              3) You can rollback the change if it is a mistake. (deploy job).


              4) Maybe you give rbac map to root for console access but not via nsh. There is a trick here with custom commands since the "nsh" custom command would still give them root access so you would have to lock down custom commands.


              5) Try to reassure them that unless a user or role is explicitly mapped in the users file, everyone else is denied access. (I am assumming you have nouser set with no arguments in the users file)