Controlling Administrative Access to vCenter 4.x
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.
Great post, thanks Chris. One thing I will add is that I find it’s really helpful to organize VMs into folders under the VMs and Templates view. Not only does that make assigning permissions to the application owners easier but also lets you have easier control over backups with products like Veeam.
One more point – don’t go too crazy with permissions if you can avoid it. To the best of my knowledge there is no easy way to export/import permissions if you have to move to a new vCenter database. I know some folks who had this issue when doing migrations to new vCenter 4.1 servers (because of the 64-bit requirement) who wanted to start with a clean database. I think there are some PowerCLI scripts to help with that now but nothing I have tried personally.
Thanks Matt, your comments are appreciated.
I agree completely about organizing objects using folders in the VMs and Templates view. I didn’t go too detailed into the layout of folders as I have already blogged on this previously in my “Layout, Naming, and Organization” post. I’ll add a reference link to this post.
http://wahlnetwork.wordpress.com/2011/03/24/vsphere-objects-layout-naming-organization/
I had not thought of the impact of losing the database on having to recreate permissions, this is a good gotcha point!
All of the information about your vCenter environment is stored in that database – so if you build a new vCenter server all you will need to do is have the ODBC connector to point to the existing database and when you install vCenter 4.1 the databse will get upgraded.Check out Section 5 of this document If you find this or any other answer useful please consider awarding points by marking the answer correct or helpful …………………. If your SQL Database is located on a separate server you could just rebuild the vCenter on the 64 bit OS and point to the existing DB. A DCSE MCP MCSA MCSE MCTS MCITP MCDBA NCDA VCP4If you find this or any other answer useful please consider awarding points by marking the answer correct or helpful.