VMware Cloud Community
stratolynne
Contributor
Contributor

Best practices for access to vCenter and VMs

Hi all,

I'm managing a site with about 25 system admins and another 5 security/remediation admins. We are ramping up to manage 14 ESX hosts. I have tried to keep administrator access to vCenter and the VMs limited to a team of 3 system admins that have been working with VMWare for awhile.

As the environment has gotten built up, we started to work with roles -- giving the other system admins access via roles in vCenter, primarily to power on and power off the VMs.

There is heat from these other system admins for various reasons to get full access (domain admin) to the server that is hosting vCenter (primarily for remediation and policy setting) and to vCenter for management of all the VMs (based on access they have to other applications and resources at this site).

What I'm interested in is best practices for access to vCenter and the VMs as well as what other sites are doing.

Appreciating any comments.

Tags (1)
0 Kudos
4 Replies
PaulSvirin
Expert
Expert

Here's the document i like very much.

Hope it will give you some new ideas:

---

iSCSI SAN software

http://www.starwindsoftware.com

--- iSCSI SAN software http://www.starwindsoftware.com
0 Kudos
AndreTheGiant
Immortal
Immortal

For power-off/on the VMs you can give only the web access of VC.

It's use the same roles of the vSphere client (but of course it's more limited in available function).

Andre

Andrew | http://about.me/amauro | http://vinfrastructure.it/ | @Andrea_Mauro
0 Kudos
stratolynne
Contributor
Contributor

Thank you both for your replies but they don't exactly address what I'm looking for.

As I mentioned there are about 25 system admins having domain access to all servers. They feel they want full access to vCenter as they have full access to all the physical servers in the domain. That its the same thing -- all system admins all access. In other words, a system admin is the point of contact for a particular set of servers yet all the other system admins have access and can make changes to these servers (for better or for worse).

I don't want to bias the discussion here but I feel that by giving them power on/power off capability they have the same access. They feel othewise, that its not fair that they don't have full access to vCenter. I think that vCenter is on par with the networking layer which the system admins don't have access to.

We have a team of 3 of us that are the VMware team. One is certified, one has lots of experience with VMware and the third has learned to use it over the past year. We are the only ones with full access to vCenter.

I'm hoping that someone can comment on this and neither help me to defend my position or explain to me why these system admins should have full access to vCenter.

0 Kudos
wbednarzyk
Enthusiast
Enthusiast

I work in a team of 10 Domain Admins. My colleague and I are the "Virtual Infrastructure" admins. We have created an AD security group named such and added our admin accounts to that group. The "Virtual Infrastructure Admins" group has full administrative rights to the vSphere, we (the two admins) have the root password to the ESX hosts, and do not share that with the rest of the team.

The reasoning for restricting VI full admin access is that the VI is a very delicate environment. Highly tuned, and running smoothly. Any admin COULD make a catastrophic mistake and cripple hundreds of servers. The rest of our team understands and respects this. If they have a request for additional resources, or some sort of Virtual Hardware change, they complete a Change Control document and submit it to us for review and action.

All local admins to any of our guest VM's have "Virtual Machine User" rights, which allows them access to the console through the VI Client. Local admins can be Domain Admins, Vendor Admin Accounts, IS Internal Application Analysts, etc...

This is a political battle for you as well as an over-all system security issue. You need to stress that getting too many hands in the pot will screw up the soup, and that they should be documenting and proposing all changes BEFORE implementing.

Good Luck!