Virtualization Adapted Adapting Business Processes for Virtual Infrastrcuture (and vice-versa)

2010/09/10

vsphere security best practices

Filed under: Uncategorized — Tags: , , , , , , — iben @ 07:54

VMware ESX 4.1 and vCenter Server 4.1

Background:

Follow the security principles of:
– separation of duties
– least privilege

Harden the hypervisor: upgrade to vSphere ESXi 4.1

Give the LAN back to the Network Team

Implement the Cisco Nexus 1000v and only assign ports to active systems.

Audit and control access

Use a tool like HyTrust to eliminate configuration drift and track and control system access.

Using Roles to Assign Privileges

A role is a predefined set of privileges. Privileges define individual rights that a user requires to perform actions and read properties.
When you assign a user or group permissions, you pair the user or group with a role and associate that pairing with an inventory object. A single user might have different roles for different objects in the inventory. For example, if you have two resource pools in your inventory, Pool A and Pool B, you might assign a particular user the Virtual Machine User role on Pool A and the Read Only role on Pool B. These assignments would allow that user to turn on virtual machines in Pool A, but not those in Pool B. The user would still be able to view the status of the virtual machines in Pool B.
The roles created on an ESX/ESXi host are separate from the roles created on a vCenter Server system. When you manage a host using vCenter Server, the roles created through vCenter Server are available. If you connect directly to the host using the vSphere Client, the roles created directly on the host are available.
vCenter Server and ESX/ESXi hosts provide default roles:

  • System roles
    • System roles are permanent. You cannot edit the privileges associated with these roles.
  • Sample roles
    • VMware provides sample roles for convenience as guidelines and suggestions. You can modify or remove these roles.

You can also create roles.
All roles permit the user to schedule tasks by default. Users can schedule only tasks they have permission to perform at the time the tasks are created.
Note: Changes to permissions and roles take effect immediately, even if the users involved are logged in. The exception is searches, where permission changes take effect after the user has logged out and logged back in.

Details:

Best Practices for vCenter Roles and Permissions

Use best practices for roles and permissions to maximize the security and manageability of your vCenter Server environment.
VMware recommends the following best practices when configuring roles and permissions in your vCenter Server environment:

  • Use folders to group objects to correspond to the differing permissions you want to grant for them.
  • Grant permissions to groups rather than individual users.
  • Grant permissions only where needed. Using the minimum number of permissions makes it easier to understand and manage your permissions structure.
  • If you assign a restrictive role to a group, check that the group does not contain the Administrator user or other users with administrative privileges. Otherwise, you could unintentionally restrict administrators’ privileges in parts of the inventory hierarchy where you have assigned that group the restrictive role.
  • Use caution when granting a permission at the root vCenter Server level. Users with permissions at the root level have access to global data on vCenter Server, such as roles, custom attributes, vCenter Server settings, and licenses. Changes to licenses and roles propagate to all vCenter Server systems in a Linked Mode group, even if the user does not have permissions on all of the vCenter Server systems in the group.
  • In most cases, enable propagation on permissions. This ensures that when new objects are inserted in to the inventory hierarchy, they inherit permissions and are accessible to users.
  • Use the No Access role to masks specific areas of the hierarchy that you don’t want particular users to have access to.

Use Host Profiles to Apply Permissions to Hosts

When you join a host to an Active Directory domain, you must define roles on the host for a user or group in that domain. Otherwise, the host is not accessible to Active Directory users or groups. You can use host profiles to set a required role for a user or group and to apply the change to one or more hosts.
It is recommended that you follow this procedure for System Administrators (Admin) and Auditors (ReadOnly).

Prerequisites

You must have an existing host profile. See Creating a Host Profile.
Verify that the hosts to which you apply a profile are in maintenance mode.

Procedure

  1. Using the vSphere Client, select View > Management > Host Profiles.
  2. Right-click an existing host profile and select Edit Profile.
  3. Expand the profile tree, and then expand Security configuration.
  4. Right-click the Permission rules folder and select Add Profile.
  5. Expand Permission rules and select Permission.
  6. On the Configuration Details tab in the right pane, click the Configure a permission drop-down menu and select Require a Permission Rule.
  7. Enter the name of the group that should have the role assigned to it.
    1. Use the format DOMAIN\name, where DOMAIN is the name of the Active Directory domain and name is the user name or group name.
  8. Select the Name refers to a group of users check box.
  9. Enter the assigned role name for the user or group (usually Admin or ReadOnly).
    1. The role name is case-sensitive. If this is a system role, you must use the nonlocalized role name. For example, for the Administrator role, enter Admin. For the Read-only role, enter ReadOnly.
  10. Select the Propagate permission check box and click OK.

Reference:

vSphere Datacenter Administration Guide : Setting Up Your Virtual Infrastructure : Managing Users, Groups, Roles, and Permissions : Best Practices for Roles and Permissions
http://pubs.vmware.com/vsphere-esx-4-1/wwhelp/wwhimpl/js/html/wwhelp.htm

No Comments »

No comments yet.

RSS feed for comments on this post. TrackBack URL

Leave a comment

You must be logged in to post a comment.

Powered by WordPress