Part 7 of the series "10 Things VMware Server Admins Should Know About Self-Service Catalogs and Lifecycle Management" that I'll be publishing over the next couple of weeks.
7. It's safe to offer your services in a catalog as long as there's robust role-based access controls down to the granular level and policies.
At larger companies, there's often a concern that if the users can see it, they'll order it. "We'll be inundated with requests and we can barely keep up as it is," I've heard some folk say.
This is where role-based access control (RBAC) comes in. RBAC allows you to create rules so that some service classes, or even individual services are viewed by some groups, departments or even individuals.
Your service catalog helps you control:
- Who can see, order or approve what services
- Who can change what services once operational
For example, certain mainframe environments are available only to application teams that work on the mainframe; while linux test servers could be available to all of QA and Development groups.
The same could be for certain VM environments. Some developers can do some basic lifecycle (start, reboot, terminate) while others may get more services (add more memory, snapshot).
The most extreme case of RBAC use in a service catalogue was the car buying service available to executives in a Mexican company. Pretty sweet.
Our service catalog at newScale can provide access control from a complete service category, to a service definition, to form component, down to a field. These get quite a bit of use. For example, you may only want the requestor to see the server password.
Having these type role based access control actually makes it easier to deploy self-service since you don't need to worry about security.