کد:
http://www.virtualizationadmin.com/articles-tutorials/vmware-esx-articles/general/using-roles-ecure-vmware-esx-infrastructure.html

David Davis


Introduction

If you think about it, both Windows and Linux have security roles. In Windows, you might be a print server operator, server administrator, or backup operator. These are some of the built-in roles that Windows calls “built-in groups” (which has been assigned special Windows rights to perform some actions). VMware is no different from these operating systems in the sense that it has its own build in security roles and that you can also create your own security roles. Let us learn more about them.
How does VMware ESX Infrastructure security work

In VMware ESX & Virtual Infrastructure, security is configured at various levels using permissions. Permissions are the core of VMware infrastructure security. These permissions are a combination of a user/group and a security role that is applied to some level of the VMware Infrastructure.
If you are using VMware ESX or ESXi without vCenter, permissions are assigned at the ESX host and VM guest level. If you are using VMware vCenter, you have additional levels of security that permissions can be applied to.
For example, there is a permission tab, shown in Figure 1 below, at the VM Guest level.

Figure 1: VMware Infrastructure Permissions Tab
Notice in Figure 1, how the permission tab shows the user/group and the roles that form the permission that is applied to this VM Guest. The permissions tab also shows where this permission is defined at.
In the case of the permission tab in Figure 1, this permission is not actually applied at the level of this VM Guest. This permission is applied at the Hosts & Clusters level (the highest level in the VMware Infrastructure Inventory).
But what about roles? That’s what this article is about so let us get on with that…
How do you use Roles to Secure your VMware ESX Infrastructure?

While VMware Infrastructure Security Roles are used in the Inventory section of the VI Client, they are not defined there. Roles are defined by clicking the Administration view, shown below in Figure 2.
VMware Infrastructure Administration view contains:

  • Roles – what we are covering in this article
  • Sessions – who is logged into vCenter and the message of the day
  • Licenses – what licenses are in use, what types, by what servers, and how many remain
  • System Logs – VMware ESX & vCenter system logs


Figure 2: VI Client Administration view to add a role
On the Roles tab, you will see the currently defined security roles for your VMware Infrastructure. If this is the first time you have been in here, likely these are the default roles. Some of the more important default VMware Infrastructure Roles are:

  • Read-Only – just what it says, for any object that has the read-only role defined, the security group user associated with it will have only the ability to view (read) the status of that object. For example, perhaps the IT Support Help Desk group should have read-only access to all VMs so that they can check status to see if a VM is up or down.
  • Administrator – by default, the virtualization omnipotent power role that the administrator user will have across the entire infrastructure. Very likely, you shouldn’t assign the administrator security role to anyone or any group because you need to be more selective. You need to apply the “principle of least privilege” and assign the least amount of privilege required for someone to do their job. For example, if someone just needs access to administer a single virtual guest machine, then they just need the virtual machine administrator role, below.
  • Virtual Machine Administrator – this is the ideal role to assign to a user or group of users that need to manage a virtual machine (or group of VMs) that are specific to their area. For example, perhaps you have database administrator (DBA) who needs to manage four SQL Server VMs. You could assign that DBA (or the DBA group) the virtual machine administrator role on those VMs. Even better, you could create a folder in your virtual infrastructure, put the SQL servers inside, and assign the DBA group the Virtual Machine Administrator role on the entire folder.
  • Data Center Administrator – in larger virtual infrastructures you will have multiple virtual datacenters administered by multiple groups of administrators. To properly secure and design this in vCenter, you create virtual data centers, move the appropriate ESX hosts and VM guests into them, and apply the data center administrator role to them, combined with the proper security group for the administrators who will manage that virtual data center.

Again, these are just a few examples of default roles. A couple common examples of how these roles would be assigned are:

  • Administrator Role could be assigned to the Windows Administrators security group
  • Read only role could be assigned to a help desk group

While the default roles are very usefully, likely you will want to create custom roles. To add custom roles, click Add Role, select a set of privileges, and give the role a name. Alternatively, you can also clone an existing role and modify it.
Let us add a new SQL Server DBA Support Role by cloning an existing role. To do this, I go to Administration, select the Virtual Machine Administrator Role, and click on Clone Role. A new role is created called Clone of Virtual Machine Administrator. Now, I right-click on this role and click Edit Role. I then rename it and call it SQL Support.

Figure 3: Cloned Security Role
Now that we have our new role, we need to apply it to some VM guests, a folder, or cluster in our virtual infrastructure. In our case, let us say that we have a DRS/HA cluster of SQL Servers called SQL Server Cluster. Back in the Inventory view, I click on my SQL Server Cluster, then on the Permissions tab. On thepermissions screen, I right-click in the white-space area and click Add Permission, as you see in Figure 4.

Figure 4: Adding Permission to the SQL Server Cluster
I now select the new custom role we created, SQL Support and click Add to add a user or group. In my case, I select the SQLServer2005Admin Group that was already created and click OK. We now have our new custom role assigned to the entire cluster. As we close to propagate this permission, this permission also applies down to all the objects in this cluster. However, as we copied the virtual machine administrator role, this group of SQL Admins should only have permission to manage the virtual guest machines in the cluster, not the cluster itself or the ESX servers in the cluster. Here is what it looks like:

Figure 5: Assigning Permissions
Instead of cloning an existing role, you can also create your own role. This is also done by going into the Administration view. From there, just click on Add Role.
As you see in Figure 6, you just give your role a name and check off the privileges you want to assign to it.

Figure 6: Creating a custom role
Here are a couple examples of other ways that custom roles could be used:

  • Virtual Machine Power Off / On – assigned to an admin for a particular virtual machine application (using the principle of least privilege by assigning only what the user needs vs assigning the virtual machine administrator role)
  • Console Interaction – this is likely to be combined with the virtual machine power off/on privilege. This privilege allows the user to perform VM guest console remote control.

Conclusion

In this article, we learned what VMware ESX Server security roles are and why you need them. If you think about it VMware ESX Server security roles and permissions are no different than any other operating systems that you are likely already familiar with. I highly recommend you plan and implement security, using ESX roles and permissions, in your virtual infrastructure



موضوعات مشابه: