The VMware vCenter 4.x product is built upon a Windows Server platform, and like it or not, is subject to some of the rules of the underlying operating system. I think a quote from the Matrix Reloaded puts this best:
There’s a building. Inside this building there’s a level where no elevator can go, and no stair can reach. This level is filled with doors. These doors lead to many places, hidden places, but one door is special. One door leads to the Source. This building is protected by a very secure system. But like all systems it has a weakness. The system is based on the rules of a building. One system built on another.
Fancy stuff! I’m not saying that vCenter “has a weakness”; the point I’m trying to drive at is that fresh out of the box, many more people may have Administrative access to your vCenter environment than what you may (or probably should) feel comfortable with.
The Rules of the Building
When Windows Server (version agnostic) is installed, the default configuration is for the local server’s Administrators group to contain the Domain Administrators group. This is so that those given that level of access, your trusted Domain Administrators, can configure and support the system. This is what it is: I see no reason to change this unless your security policy dictates otherwise. However, this group is rolled up into the vCenter environment as the root (vCenter level) Administrators role. To see this, click on the vCenter object from the vSphere Client and then choose the Permissions tab. This is the default configuration:
This is okay for initial setup and configuration needs, as someone needs access to begin with, right? However, once you have your crown jewels stored in vCenter, it’s time to get serious about setting some real roles and permissions.
What if you don’t change this default security configuration? Imagine if …
- You have some sort of lower tier support group that is granted access to the server to do maintenance?
- A Domain Administrator is hired by the company and takes a tour through vCenter?
I think you can see my concern here. Hope for the best, prepare for the worst.
Protecting the Building
I have a few thoughts as to how to set up permissions for vCenter.
Root level access tips
- The root level of vCenter should be your absolute most trusted, capable personnel when it comes to vCenter.
- Root level access should be primarily assigned to individuals, not groups. This makes managing the environment more transparent and changes are logged by vCenter tasks & events – which you have control over.
- Chances are you don’t need many people to have this degree of access.
- Once you’ve assigned individual access (don’t forget yourself), remove the vCenter’s local server Administrators group from vCenter.
- You may need to assign service accounts to this level, but not necessarily give them Administrator role access.
Sub level access tips
- Groups are okay when they make sense – just remember that you may not have control over groups, and those that do should respect what sort of access they are handing out.
- When applicable, make special security groups that are clearly defined as having vCenter access. Don’t resort to using “Marketing Department Users” unless that is specifically the best group for having access.
- While the default roles are sometimes okay, they tend to be heavy on permissions. Create or request a test account, assign a role to it, and fiddle around until it works as intended. Add permissions only if needed.
- Aside from the root (vCenter) object, permissions have two “paths” to go down: the Hosts and Clusters side, and the VMs and Templates side. It may be necessary to assign permissions on both “paths” in order to grant the level of access requested.
Hiding access tips
- Anything that a user doesn’t explicitly have access to (either because it is not a child object or because you did not enable propagation) is hidden from the vSphere Client. This includes the objects, tasks, events, logs, etc. To these users they simply do not exist.
- Use the “no access” role to hide child objects when turning off propagation would require too many additional permission entries. For example, if you have a folder with 10 child objects inside, and you don’t want the user or group to see a single object within, you could assign that object the “no access” permission.
- Explicit permissions supersede inherited permissions. This is a bit different from what you may be used to with NTFS permissions.
Thoughts
Take the time to really think out the security of your vCenter environment. With virtualization comes shared resources, consolidation, and ease of administration, but that also means it’s less work for someone to cause harm to the system.
