Security strategy for access to vCenter Server

[TheVMinator]

Scenario:

Users need to have various levels of access to virtual machines.  Some need only to be able to power on , restart, and power off VMs.  Some need to take snapshots, power on, power off, and restart.

Others need to be able to do anything.

There is an existing Active Directory server.

We don't want to overwhelm vCenter server with too many simultaneous connections.  Over 3000 users need to power on and power off VMs and take snapshots.

Less than 50 administrators need full privileges in vCenter Server.

We need to use AD where possible to define groups of users who have various privileges.

What are the strategies for doing this?  Should we create a set of "jump VMs" in a special security zone for those who need access to vCenter Server to power on VMs and take snapshots?

What security products facilitate these kind of scenarios?

Eventually vcloud or vCenter Automation Center, vCenter Operations Manager will be used.  The solution needs to be able to integrate with the full set of VMware management products as opposed to replacing them.

Thanks for your input.

[maishsk]

Giving 3000 users access to vCenter is a BAD idea. The same way you would not let everyone into your datacenter to start "playing" with servers, you should not allow all your users access to vCenter.

Give them RDP/SSH if they need it.

In any event, vCenter does not support more than 100 concurrent vSphere client connections.

[TheVMinator]

I agree that giving these users direct access to vCenter Server is a bad idea.  However, there are products that serve as an interface between the user and vCenter Server, that allow users to do something like power on a VM, without accessing vCenter server directly.  For example, Tivoli creates such a product although I don't remember the name, and there are others out there as well.

So for example, if there are 3000 users, you could give them a login to your management software, which would pass requests on to vCenter server.   This piece would disallow connections to vCenter server that would exceed capacity.  The assumption is that all 3000 users are usually not going to want to power on their VMs at the same time.  In events such as after a maintenance window, when a large number of users DO want to power on their VMs, your management software can throttle the number of requests to vCenter Server back to prevent it from being overloaded.

You don't want 3000 people with admin rights, and you don't want 3000 people hitting vCenter Server simultaneously, but you also don't want 3000 support tickets created whenever people need to power on a VM or create a snapshot.  This is especially true in a test / dev environment.  Software developers that are building environments in VMs and so on.  RDP is great for regular / normal day to day access - agreed there.

I'm looking to see who has faced a problem like this and come up with a solution.  Based on the fact that there are solutions out there that work better than just hitting vCenter server directly by end users, I'd like to know what they are.  Also, there are considerations for actual admins like creating a special security zone with "jump VMs" for access to vCenter server.  I'd like to get the whole picture.

In addition, one constraint here worth noting, is that saying "No - users will NOT have access to power on VMs, they will NOT do anything that impacts vCenter Server or creates an event in vCenter server" is great for an admin to say when they are given the authority.  But admins work under managers - and sometimes managers create requirements that defy best practices.  We still have to implement those requirements as best as possible and mitigate the risk and impact as best as possible having explained the risk.  So assuming that this actually NEEDS to be done by management requirement, how to best proceed.  Thanks for input,.

[maishsk]

Two options that come to the top of my list - but both do not cover your requirements out of the box.

vCloud Director - Self provisioning, management, isolation - but I am sure you know the benefits, true there is a cost that comes with with it, but it could suit yout needs.

vCenter Orchestrator - Cost - none. Development costs to precisely suit your needs - could be quite substancial.

[TheVMinator]

thanks for the input.  Other than vCenter server/vSphere Client, Web Client and RDP, what are the other solutions that actually provide console access for a VM?

[Texiwill · Accepted solution]

Hello,

Actually, you do not want to generically allow console access to a VM, instead if you do allow console access to a VM you want to monitor that access quite closely as it (other than RDP) goes through the virtualization management services (ala vCenter). I would use tools such as HyTrust, Xceedium, Thycotic, etc. to monitor/audit such access. Personally, I tell my system administrators to just use RDP as it does not go through the virtualization management layers. If they need CD access for example, I provide other means to access ISO images from a common share (VCD, loop mounts) instead of requiring someone to use vCenter.

A poor man's way of gaining the same functionality is to create a proxy service that logs all requests for console access and acts as additional security gateway into the virtualization management device(s) (ala vCenter). This way a request to access the virtual console directly is logged properly and you can use that same proxy to make requests to mount/unmount images, etc. Using a proxy, hytrust, Xceedium, or Thycotic you can let them manage the 3000 user's requests, limit the # of connections allowed at any given time (which is a must), set timeouts, but most importantly you can delegate everything through a service account inside vCenter so that you can gain better control of your environment. The logging these tools provide is enough to meet audit requirements.

The best suggestion however is to just not allow it. I have been running a virtual environment for years now and direct access to the console of a VM has just not been necessary. You want complete separation between virtualization management and the rest of the world.

Best regards,
Edward L. Haletky
VMware Communities User Moderator, VMware vExpert 2009, 2010, 2011,2012,2013,2014

Author of the books 'VMWare ESX and ESXi in the Enterprise: Planning Deployment Virtualization Servers', Copyright 2011 Pearson Education. 'VMware vSphere and Virtual Infrastructure Security: Securing the Virtual Environment', Copyright 2009 Pearson Education.

Virtualization and Cloud Security Analyst: The Virtualization Practice, LLC -- vSphere Upgrade Saga -- Virtualization Security Round Table Podcast

[TheVMinator]

great thanks again