Templates are harder to administer. We give people VM User, to power on / power off their VM's. They are Windows admins. Maybe some companies have a need to allow more people access to deploy their own templates, but that is opening yourself up. I prefer to keep it limited, they request a VM, I give them what they ask for, and they can do whatever they want inside the VM.

I figure all they need (once the VM is deployed) is to power it on if it's off, or reset if it gets stuck. I experimented with VM Admin, but templates is tricky, because you have to give them top level access to the datacenter where their VM is, but not propagate. Then drill down to where the VM lives in a Resource pool or ESX host. Then give them rights to that machine / pool. And sometimes they still can't get proper authority to deploy templates, because they need root level to the SAN storage. I tried on different hosts and its a nighmare to manage.

I found it easier to just deploy whatever template they want (you can even schedule it) and if you design the templates properly they can build themselves you just initiate the sequence, and after 30 minutes, it adds itself to the network, reboots, updates itself.. all automated, then its ready.

But I see your delima, It's tough to know who to trust, but I say keep it confined to a very small number of people for deployments and VM Console access, you are just asking for trouble if you get someone that doesn't know what they are doing.. and there are MANY that say they understand, to find out they don't really understand at all. That's ok if you do it to your own VM, but I don't want to come in on a Sat at 4:00am to fix an issue because somebody 'thought' they had it.

Hello,

THe best security is to actually not allow anyone but virtualization administrators have access to the vCenter Server, or VIC to SC. Basically only VI Admins should have access to the VIC.

All other managemernt can take place using ISO images, and RDP to the console if necessary. THere is no real need for a server admin to get to the server(guest) console through the VIC when they can do this quite easily using RDP.

VIC access actually makes things harder to manage I find unless you limit its scope of use.


Best regards, Edward L. Haletky VMware Communities User Moderator, VMware vExpert 2009
Now Available on Rough-Cuts: 'VMware vSphere(TM) and Virtual Infrastructure Security: Securing ESX and the Virtual Environment'
Also available 'VMWare ESX Server in the Enterprise'
SearchVMware Pro|Blue Gears|Top Virtualization Security Links|Virtualization Security Round Table Podcast

Hello,


If RDP hangs or there is a server reboot issue you may actually have a different problem that a reboot may not actually fix. This is a case of the Server Admin must work with the Virtualization Admin to either fix the problem or determine the root cause of the problem.

If you were to expose this capability to non VI-Admins then I would do it through some other mechanism besides vCenter/VIC/vSphere Client/Power Shell/etc. Perhaps just through a process where the Server Admin contacts the VI Admin, etc. That would be the best suggestion as something is definitely wrong with the VM.

Otherwise you could create a custom tool that would contact a proxy which would then go through the firewall to the VI Admin network and then execute a VI SDK script to perform the reboot. Note you do not want to expose the VI SDK through the VI Admin network firewall but something else unrelated.... I have been thinking about the best way to do this recently as well. There exist at least one tool that does do this now. You use one set of credentials to access the proxy and it uses another to do the reboot, etc.... Hyper9 Virtualization Mobile Manager 1.0... Which is available from http://www.hyper9.com/downloads.aspx .... It is not quite what you want (nothing exists yet), but close to what you need and has the necessary security to do the work.


Best regards,
Edward L. Haletky VMware Communities User Moderator, VMware vExpert 2009, Virtualization Practice Analyst
Now Available: 'VMware vSphere(TM) and Virtual Infrastructure Security: Securing the Virtual Environment'
Also available 'VMWare ESX Server in the Enterprise'
SearchVMware Pro|Blue Gears|Top Virtualization Security Links|Virtualization Security Round Table Podcast