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.
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
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)