Virtualization Pro

Nov 17 2008   6:31PM GMT

Security outside the box

Texiwill Edward Haletky Profile: Texiwill

Virtualization security depends on more than securing the virtualization host and hypervisor. It depends on everything that touches your virtualization host, directly or indirectly, also being secure.

Let us take a quick look at the daily operations you may perform within your virtual infrastructure.

  • Create/Move/Modify virtual machines (VMs)
  • Backup/replicate VMs
  • View performance and other data about hosts and VMs
  • Install/Reinstall/Update hosts
  • Add or remove administrative users from VMs and hosts
  • Monitor your VMs and hosts
  • etc.

The list is quite endless. Each one of these actions will affect security or be affected by security.

Ease of use, ease of administration is sometimes paramount. This is the age-old debate of security over usability. Do not knock holes in your firewalls, instead, use existing secure protocols to improve the experience. One I use is OpenVPN to access my administrative network workstation using pre-shared keys for encryption. The extra step of starting up the VPN is trivial with the service provided, this gives me secure access to the management network over which the tools can be run.

Affected by Security

There will be at least one more step involved in use of daily tools then you would normally use. Mainly some way to ensure your access to the management tools is secured from sniffing by your non-administrative network. Or the use of different procedures to ensure you have proper auditing in place.

One tool I use is a simple expect script called expectsudo which will allow me to run remote commands on my VMware ESX hosts while retaining logging of all access. To use this tool you must first install the expect RPM onto your host. Then setup sudo to allow access to the appropriate commands.

#!/usr/bin/expect --
set pass [lindex $argv 0]
set timeout 5
spawn /usr/bin/sudo [lrange $argv 1 end]
expect "Password: {send "$passr"; exp_continue
sleep 1

In the above script the first argument will be the password to use. This script can not be run remotely using any form of SSH. For example:
ssh user@hostname expectsudo password esxcfg-vswitch -l
The only drawback to this script is the need to have the password available, instead you can setup pre-shared keys for SSH and setup Sudo to allow the  user to issue certain commands without requiring a password. This form of single sign on relies on the security of the management workstation in use.

Security of your VMware Infrastructure relies on the security of all the management workstations and servers in use. Not just on the hardening of the VMware ESX host.

2  Comments on this Post

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.
  • Shokk
    Anyone doing a "ps" on that system is going to see the password for user@hostname, so even if the management workstation is secure, you're potentially broadcasting a password to other users of that workstation who might not be authorized to have it.
    15 pointsBadges:
  • Texiwill
    Hello, Correct. THat is why it is more advantageous to use pre-shared keys and setup sudo for the specific commands this script will use to not accept a password, or setup expectsudo to ask for the appropriate password. expect is a TCL enhancement so either will work. Use of such tools also depends on the security of your management workstation. Best regards, Edward L. Haletky
    0 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: