Chapter 2 Configuring and Administering Security in a vSphere Datacenter

2V0-21.19 EXAM OBJECTIVES COVERED IN THIS CHAPTER:

• Section 1 - VMware vSphere Architectures and Technologies

  • Objective 1.9 - Describe the purpose of cluster and the features it provides

• Section 2 - VMware Products and Solutions

  • Objective 2.3 - Describe the options for securing a vSphere environment

• Section 4 - Installing, Configuring, and Setting Up a VMware vSphere Solution

  • Objective 4.2 - Create and configure vSphere objects
  • Objective 4.7 - Set up identity sources
  • Objective 4.8 - Configure an SSO domain

• Section 7 - Administrative and Operational Tasks in a VMware vSphere Solution

  • Objective 7.4 - Configure host security
  • Objective 7.5 - Configure role-based user management
  • Objective 7.11 - Manage different VMware vCenter Server objects
  • Objective 7.12 - Setup permissions on datastores, clusters, vCenter, and hosts

This chapter focuses on how to secure ESXi hosts, virtual machines, and other infrastructure components in a vSphere 6.x datacenter.

Securing all access points into a vSphere implementation should be considered even more important than securing a traditional datacenter. In a traditional datacenter, bypassing security on a single server would allow access to data on only that server. But a single ESXi host could be running dozens of virtual machines, each containing potentially valuable data. Also, in addition to taking security precautions within each virtual machine, you must also take precautions with the ESXi host itself, as well as other virtualized components within the vSphere environment.

The vSphere Web Client provides a centralized access point into the virtual machines running within the datacenter. One of the first steps that should be taken in securing the environment should be ensuring that each user and group has the smallest degree of access to each virtual machine as is appropriate for their role within the company. Normally, this could be cumbersome to administer, but vSphere provides the ability to customize roles as needed to provide the exact grouping of privileges required. It also allows that permission set to be propagated to child objects, simplifying the need to assign permissions on multiple objects within the hierarchy.

Next, steps should be taken to harden both the ESXi hosts running virtual machines and the vCenter Server system. The term harden comes into play because both the ESXi hosts and vCenter Server come with a degree of security out of the box. The idea behind hardening is to make adjustments to the inherent security of these vectors in order to reduce the attack surface as much as possible without overly impacting usability of the environment.

Identity management, certificate management, and licensing management for ESXi hosts and vCenter Server are provided by the Platform Services Controller (PSC). There are multiple methods of deploying the PSC depending on design requirements, including a high-availability solution available starting with vSphere 6.7. Once deployed, the PSC provides a SAML-token-secured, encrypted pathway for communications-critical components within the environment. Two-factor authentication is supported using smart card or RSA SecurID methods. Certificates are managed by the VMware Certificate Authority (VMCA), which can act on its own or as a subordinate of an enterprise or third-party CA.

The final point of security to be considered is the virtual machine itself. The guest OS in a virtual machine is subject to the same risks it would be subject to on a physical system, so the same security precautions should be taken. In addition, starting with vSphere 6.5, virtual machine encryption is supported, which can be used to protect virtual machine files, virtual disk files, and core dumps. Finally, some additional steps can be taken to harden this vector and further reduce the attack surface of the vSphere implementation.

Configuring and Administering Role-Based Access Controls

Security in a vSphere environment is a delicate balancing act. Users that perform day-to-day activities within the environment typically have a set of duties that require access to specific objects, along with the ability to perform actions on those objects. At the same time, a user should be restricted from accessing objects that are outside the scope of their duties. In the case where the user does have access to an object, they still should be limited to performing the actions on those objects that are necessary for their job.

In vSphere, these actions are referred to as privileges. When a user is granted one or more privileges on an object, the collection of privileges forms their permissions governing the use of that object. Finally, the collective group of permissions and objects a user can access makes up that user's permission set.

The determination of objects and privileges is closely tied to the user's duties, or job role. Because the defining of permissions is tied to a job role, this is referred to as role-based access control (RBAC). The following sections focus on RBAC.

What Is a Privilege?

A privilege is an action that can be taken in a vSphere environment. An example of a privilege is Network.Assign network, which assigns a network to a virtual machine. There are over 275 privileges that can be assigned in vSphere 6.7, which would be extremely cumbersome if an administrator were required to assign every privilege individually. Thankfully, this is not necessary, since privileges can be grouped together for easier assignment. This grouping is done based on tasks and roles.

What Is a Task?

A task is a duty a user has to perform as part of their job role. In many cases, multiple privileges are required to perform a task. An example of a task might be to create a virtual machine, which requires the following privileges:

• Virtual machine.Inventory.Create new
• Virtual machine.Configuration.Add new disk
• Resource.Assign virtual machine to resource pool
• Datastore.Allocate space
• Network.Assign network

Other common tasks and related privileges can be found in the vSphere Security Guide.

In some cases, it might be appropriate for a single user to have all of these privileges. For example, an administrator would typically have all of the above privileges. However, it may not always be advisable for a user to have all of these privileges even if it is part of their job role to perform the related task. In this case, if it is an application owner's duty to create virtual machines for related applications, the owner may be limited to a specific resource pool or network. So in some cases, it may be necessary for the owner to request some portion of the tasks to be performed by another user, such as a Resource Pool Administrator.

What Is a Role?

A role is a grouping of privileges based on a specific set of tasks that must be performed within a vSphere environment. If a user is in the job role of managing the content library for virtual machine administrators, they might be assigned the content library administrator role, which contains the following privileges:

• Content library.Add library item
• Content library.Create local library
• Content library.Create subscribed library
• Content library.Delete library item
• Content library.Delete local library
• Content library.Delete subscribed library
• Content library.Download files
• Content library.Evict library item
• Content library.Evict subscribed library
• Content library.Probe subscription information
• Content library.Read storage
• Content library.Sync library item
• Content library.Sync subscribed library
• Content library.Type introspection
• Content library.Update configuration settings
• Content library.Update files
• Content library.Update library
• Content library.Update library item
• Content library.Update local library
• Content library.Update subscribed library
• Content library.View configuration settings

There are two types of roles in vSphere: system roles and sample roles. There are five system roles, as follows:

• Administrator Role The Administrator role contains all possible privileges. Assigning a user or group this role against an object ensures that they can perform all possible actions on the object. This is also the only role that can be used to assign privileges to other users and groups. This role is assigned to the local administrator account by default
• No Cryptography Administrator Role The No Cryptography Administrator role contains the same privileges as the Administrator role, except for cryptographic operations privileges. This role allows an administrator to assign administrator privileges to other users or groups while restricting them from encrypting or decrypting virtual machines or accessing encrypted data.
• No Access Role The No Access role restricts a user or group from viewing or changing an object in any way. This role is assigned to new users and groups by default to prevent access until appropriate privileges can be assigned. This role can be used in addition to normal privileges to mask specific areas of the hierarchy from a user or group.
• Read Only Role The Read Only role allows a user or group to view the state and details of the object it is applied to. A user or group with this role on a virtual machine would be able to view its attributes but would not be able to open a remote console to the VM.
• Tagging Admin Role The Tagging Admin role allows a user or group to manage tags that are applied to objects in the vSphere inventory. A user or group with this role can create, edit, delete, or modify tags as well as assign and unassign them.

System roles are permanent fixtures in vSphere, so it is not possible to make any changes to them. However, these are not the only roles available in vSphere. A number of sample roles are also included, and these can be modified as needed. The included sample roles are as follows:

• Content Library Administrator Role The Content Library Administrator role allows a user or group the ability to monitor and manage a library and its contents. Users and groups with this role can create, edit, and delete libraries, synchronize a library, configure library settings, and import/export items to/from a library.
• Resource Pool Administrator Role The Resource Pool Administrator role allows a user or group to create child resource pools or modify the configuration of existing child pools. This permission is usually assigned on a parent pool (or a cluster), which cannot be modified by users or groups assigned this role. Additionally, the role also allows the granting of permissions on child pools and the assignment of VMs to child or parent pools.
• Virtual Machine Power User Role The Virtual Machine Power User role allows a user or group to interact with and make changes to a virtual machine. Examples would be modifying vCPU or memory settings or adding a vDisk. This role also includes the ability to manage snapshots and schedule tasks on a VM.
• Virtual Machine User Role The Virtual Machine User role allows a user or group to perform power actions on a virtual machine. It is typically combined with additional permissions or roles and is very effective when used with VM folders to grant power users control over a group of virtual machines. Additional actions include the ability to insert media as well as open a remote console to the VM.
• Datastore Consumer Role The Datastore Consumer role allows a user or group to consume space on a datastore and restricts a user or group from viewing or changing an object in any way. It is typically combined with additional permissions or roles when a user or group needs to create snapshots or virtual machines.
• Network Consumer Role The Network Consumer role allows a user or group to assign virtual machines or hosts to a network, assuming the user or group also has the appropriate permissions on the related VMs or hosts.
• VMware Consolidated Backup Role The VMware Consolidated Backup role is for the most part a legacy role, but it still can be used to allow a user or group the appropriate permissions to perform snapshot and backup actions in conjunction with VMware Data Protection or a third-party backup platform.

To change one of these roles, select the role in the vSphere Web Client and click the Pencil icon. The Edit Role window is displayed, allowing privileges to be added or removed as necessary. For example, let's say you wanted to take the Datastore Consumer role, which is limited to allocate space, and expand it into a Datastore Administrator role, with all datastore privileges, including the ability to browse, configure, and move a datastore. An example is shown in Figure 2.1.

Although it is possible to edit these sample roles, they serve even better as templates in the creation of new roles. If used in this way, it would be preferable not to make changes to the sample roles. This is easily accomplished by cloning the sample role, then making changes and saving the result as a new role. For example, if you wanted to create a role similar to the Virtual Machine Power User role but wanted to add the ability to configure virtual machine fault tolerance, you would select the Virtual Machine Power User role in the vSphere Web Client, click the Clone icon, supply a name for the new role, and add the privileges as shown in Figure 2.2.

While cloning sample roles is a convenient way to create custom roles, you may sometimes need to create a new role from scratch, particularly if there are no sample roles that closely match your permission requirements. If you do need to create a role, it is a VMware best practice to grant permissions only to the objects needed in performing the tasks the role comprises and to use the minimum number of permissions required for each task.

Assigning Permissions

Now that you have an understanding of privileges, tasks, and roles, let's look at how to assign a user or group to an object with a specific set of privileges. To perform this action, begin by selecting an object. It is a VMware best practice to group both objects and users together to minimize management overhead. For objects, such groupings would include the entire datacenter, specific clusters, resource pools, or folders containing specific groups of virtual machines. Users should be grouped by job role whenever possible.

For the example shown in Figure 2.3, we are selecting the entire datacenter. This is because the group that we will assign to the datacenter is responsible for creating virtual machines within the both the Sales cluster and the Finance cluster. This assignment will also allow the group to create VMs regardless of future cluster, resource pool, or folder locations. The next step is to assign a user or group to the object. In this case, I have grouped together users who will share the same responsibility for creating virtual machines, and this is the group I am assigning to the object. Finally, I select a role for the group on this object. Since there is no system or sample role that is limited to creating virtual machines, I have created a custom role limited to the privileges necessary to perform this task. The workflow would look like Figure 2.3.

When assigning permissions on an object, think about both user and group requirements as well as the collective objects that need to be utilized. This will help determine whether you make an explicit assignment to an object or propagate permissions to a group of objects. Take Figure 2.4, for example.

In this use case, the Finance group works with a number of virtual machines (VMs) on a regular basis. As a result, all of those VMs have been grouped into a folder labeled Finance. By assigning the Finance group to the Finance folder and propagating their permissions, not only does the group get access to each VM in the folder with the exact same permissions, but they will gain the same level of access to any future VMs that are placed into the folder. Not only does this follow best practice, it also minimizes management overhead as this assignment only needs to be done once. Any future users added to the group or VMs added to the folder will automatically acquire the same configuration.

However, in some cases you may need to explicitly assign a user to an object. In the use case, there is a Receivables user. This user does a very specific job and should not be granted access to other Financerelated VMs, only to the VM that runs the Receivables app. The explicit assignment provides the exact level of access needed, albeit at a higher level of management overhead.

The way permissions on inventory objects behave can change dramatically when a user has multiple possible permissions assignments to the object. There are two primary instances when this occurs. The first is when a user is assigned to multiple groups and those groups are assigned to the same object, as shown in Figure 2.5

In this example, Jack is a member of both the Server Admin group and the Finance group. The Server Admin group has all permissions necessary to perform power options and to configure VM resources but no permissions to interact with the VM or guest (such as inserting media, opening a console, etc.). The Finance group has permissions to interact with the VM and guest but no ability to change VM configuration settings. Because Jack is a member of both groups, and both groups have been assigned to the Finance folder, Jack is given the aggregate of permissions for both groups. This means that Jack can change the configuration of the VM and interact with it as well.

The second instance occurs when a user is part of one or more propagated assignments but has an explicit assignment to a child object. Figure 2.6 provides an example of this.

When this situation occurs, the explicit assignment overrides any propagated permissions. A good example of this would be if Jack was a member of the Server Admin group, which can configure VMs in this folder, but Jack needs to have total access to the VM. Assigning Jack the Administrator role on this VM would override the propagated assignment and allow for complete access to the VM.

However, care should be taken when applying this type of assignment. If, for example, Jack was given a Read Only role on this VM, he would be restricted to those permissions, which would override the greater degree of control that was granted to him by the propagated role.

Viewing and Exporting Group and User Permissions

To see the current permission settings on an object, select the object in the navigator and click the Permissions tab. The current list of users and groups that have permissions on the object and the role they have been assigned on the object are displayed. Figure 2.7 is an example.

In the Flash-based client at the bottom of this screen, there is a button that can be used to export the list. The list will be exported in CSV format. Figure 2.8 is an example.

Validating Users and Groups

Before a user is assigned permissions on objects in vCenter Server, they must first be validated. Validation is done against the selected identity source. For more on identity sources, see the section “SSO and Identity Sources” later in this chapter.

vCenter Server periodically reviews current user and group lists and compares them to information in the user directory. Any users or groups that no longer exist are removed. This is done to maintain security in the environment and can be customized as needed. First, it is possible (though not recommended) to disable validation entirely. This may be something that is considered in a large, enterprise implementation, since the validation process has to search the user directory, which may consist of multiple domains and thousands of users or groups.

Rather than disabling validation entirely, consider modifying the validation period so that validation is not done as often. You can even limit the scope of the queries performed. In this way, you can maintain a high level of security while maintaining a reasonable level of performance on the vCenter Service system.

To make these adjustments, highlight the vCenter server in the navigator, click the Configure tab, then click the Edit button. The Edit vCenter Server Settings window is displayed. Click User Directory on the left, then make changes to the settings as needed (Figure 2.9). The validation period is entered in minutes, with the default setting set at 1440 minutes, or 24 hours.

Securing ESXi Hosts and the vCenter Server

Establishing security on specific objects in your vCenter Server inventory is the first step to creating a secure vSphere implementation. However, this is only the first step. Although virtual machines and other objects in your inventory are now secured, there are additional steps that must be taken to secure the platform itself. This includes securing both the vCenter Server system and all of the ESXi hosts in the environment. This activity is commonly referred to as “hardening,” and the following sections are devoted to the steps that must be taken to “harden,” or improve, security of the infrastructure components that are a part of the vSphere implementation.

Hardening ESXi Hosts

First, let's take a look at the process needed for hardening ESXi hosts in the environment. Certain steps are taken by default to provide a basis for a secure implementation. These include CPU, memory, and device isolation as well as a robust firewall. Finally, starting with vSphere 6.0, ESXi hosts are provisioned with certificates. By default, these certificates are signed by the VMware Certificate Authority (VMCA), but this can be changed, as you will discover.

The first step in hardening an ESXi host is to ensure that the host is regularly patched. If a vulnerability is exposed on the host, VMware typically will release a patch designed to eliminate or at least mitigate that vulnerability. If a vulnerability becomes known and your hosts are not properly patched, they become an easy vector for attackers to take advantage of.

Next, you should regularly audit your hosts for any changes that might compromise security. Two areas that should be regularly audited are exception users and the host's SSH configuration. Beginning with vSphere 6.0, users can be added to an Exception Users list via the vSphere Web Client. These are users who would continue to have permissions even after the host enters Lockdown Mode. This is sometimes necessary for things like service accounts but should be an exception for user accounts and should be regularly monitored to ensure that only authorized users are on the list.

SSH provides a means to access the host but is disabled by default. However, it is possible to enable this service and open up a possible means of compromising the host. Unless absolutely necessary, this service should remain disabled. If the service is intended to be disabled, regular audits may be needed to ensure that the state remains unchanged.

Certain configuration steps should be completed to ensure that if an intrusion occurs, it can be easily tracked down. These include the configuration of NTP, SNMP, and persistent logs. Configuring NTP ensures that all hosts are using an agreed-upon time source and that time is accurate across all hosts. If an intrusion occurs, this will make it easier to track the incursion down using a specific time frame. With regard to SNMP, ensure that the service remains disabled if you do not intend to use it, and if you are using it, ensure that the proper trap destination is set. Otherwise, information regarding the host could be sent to an unwanted and potentially malicious destination.

By default, ESXi hosts store logs to an in-memory file system. In this configuration, only a single day's worth of logs are stored at any given time. Not only that, if the host is rebooted, those logs are lost. To avoid this, go into the Advanced System settings for each host and configure the Syslog.global.logDir parameter to point to a desired datastore path.

So far, we have looked at patching, auditing, and service configuration. Next, we should look at settings that may need to be either enabled or disabled. Enabling certain services or settings can increase security, while disabling others can make it more difficult for the host to be compromised. Let's start by looking at disabling unneeded components.

The first component to look at is the Managed Object Browser (MOB). The good news is that this is disabled by default beginning with vSphere 6.0. When enabled, it provides a means of debugging the vSphere SDK. The other component to look at is TLS. Transport Layer Security, or TLS, is a protocol designed to provide privacy and security during a connection to the host. By default, the host is enabled to use versions 1.0, 1.1, and 1.2. Whenever possible, it is recommended to disable older versions, provided no third-party tools require an older protocol version. To configure, select a host using the web client, go into the Advanced System settings, then edit the UserVars.ESXiVPsDisabledProtocols value to disable the desired versions. You can also use the TLC Reconfiguration Utility.

Moving on, let's take a look at enablement. There are six components that can be enabled in order to further harden the host, starting with enabling Active Directory authentication. By joining hosts to the domain, you can avoid the creation of local accounts. This reduces the means of accessing the host and also reduces administrative overhead. Furthermore, you can enforce password policies configured with AD, such as complexity and reuse. Finally, you can use the AD group ESX Admins to centralize your admin users to a single permission assignment. To enable AD authentication, select a host using the web client, go into the Authentication Services, then click Join Domain.

If you decide to use Active Directory authentication and you are configuring your hosts using Host Profiles, AD credentials are saved as part of the profile and as a result can be transmitted across the network. This can be avoided by using the vSphere Authentication Proxy. The easiest way to set this up is to follow the instructions in the previous paragraph, selecting the Using Proxy Server radio button.

ESXi hosts also come with a feature called Lockdown Mode. This feature is designed to limit access to the host directly, forcing all connectivity to the host to pass through vCenter Server. Since the only method of accessing a host is via vCenter, an administrator can more easily ensure that the roles and permissions implemented through vCenter are adhered to. There are two settings for Lockdown Mode, Normal and Strict. In both cases, direct access to the host is disabled, but with Normal mode, the Direct Console User Interface (DCUI) is left operational, allowing users who are placed on the DCUI.Access list to override the lockdown and access the console. By default, only root is placed on the DCUI.Access list. Strict mode disables the DCUI service, eliminating the possibility of accessing the host using the console.

The last two areas of hardening that should be examined on the host are the password policy and firewall settings. The ESXi host has settings related to the maximum number of login attempts before an account is locked, how long an account should remain locked before it is unlocked, and of course, password strength and complexity. These should all be set, particularly if the host is joined to an Active Directory domain.

As for the firewall, the ESXi host includes a robust firewall, but some settings are not limited out of the box for functionality purposes. One of these settings is restricting access through the firewall to only authorized networks. To enable this, deselect the Allow Connections From Any IP Address check box, then add to the whitelist the network/IP ranges that you want to allow access to services. The two primary services this should be configured for are SSH and vSphere Web Access.

Hardening vCenter Server

When it comes to hardening vCenter Server, congratulations, you just completed the first step! Since the vCenter server will invariably run on an ESXi host, that host should be hardened before any steps are taken on the vCenter server itself. We have also discussed practices for setting up access through the server to objects in the inventory, another key to securing this system. Part of that process was determining who has administrator-level privileges and assigning them via an admin group. If vCenter Server has been installed on a Windows VM, it is possible that the local Windows administrator account has the Administrator role on vCenter Server. This used to be the default setting but was changed starting with vSphere 6.0. If this account does have access, it should be removed, restricting access to the accounts you have already placed in the admin group. You can further mitigate security risks by using a service account to install vCenter Server and ensuring that applications connecting to vCenter Server are also using unique service accounts. You should also restrict access to the virtual machine running vCenter Server so that only administrative personnel charged with maintaining the virtual machine or managing the database can access the system.

Since vCenter Server is running off a vDisk on a datastore, you should also make sure that access to the datastore is limited. This can be done by limiting the assignment of the Database.Browse datastore privilege to only those users that need to manage the datastores in the environment. Also, any user with the vCenter Server Administrator role can also administer the guest OS on the vCenter Server VM. This can be limited if need be by creating a custom role with the same privilege minus the Guest Operations privilege.

What remains is ensuring that password policies are properly configured and conform with the standards for your organization. By default, the vpxuser account password is set to expire every 30 days. This can be easily modified using the vSphere Web Client. The password for the administrator of vCenter Single Sign-On, administrator@vsphere.local by default, also has a specified password policy. By default, this password must meet the following requirements:

• At least 8 but not to exceed 20 characters
• At least one lowercase character
• At least one numeric character
• At least one special character

The password is set by default to expire every 90 days. As with the vpxuser account, this policy can also be modified. To do so, use the vSphere Web Client and navigate to the vCenter Single Sign-On configuration UI. The password policies are located on the Policies tab.

When operating vCenter Server, there are different security measures to take if the software is running on a Windows VM or if the vCenter Server Appliance is being utilized. Naturally, if the software is running on a Windows VM, the Windows OS should be regularly patched, protected by antivirus software, and secured just as any other Windows VM would be, in addition to the measures taken to harden vCenter Server itself. If the vCenter Server Appliance (VCSA) is being utilized, it is critical that NTP is set up properly. This is because proper certificate validation relies on synchronized servers. Furthermore, if an attack occurs, having properly time-stamped logs will make it much easier to perform an audit and identify the source of the attack.

Configuring and Enabling SSO and Identity Sources

One of the key parts of administering a vSphere infrastructure is the ability to administer, secure, and control permissions for vSphere resources. This administration could potentially become complicated when dealing with a vSphere infrastructure containing several components that each require account login and permission configurations. To centralize this administration and to simplify the login process, vSphere utilizes vCenter Single Sign-On (SSO). With vCenter SSO, a user logs in to the vSphere Web Client. The user is first authenticated against an identity source and is then issued a token that represents the user from this point on. The token is then used to validate the user, granting them access to the objects that the user's role had permissions for. The token is also used when the user needs to connect to other VMware or third-party components that are a part of the vSphere infrastructure.

vCenter Single Sign-On

When a user logs in to the vSphere Web Client with a user name and password (Figure 2.10, step 1), their information is passed on by the client to the vCenter Single Sign-On service (step 2). The service checks to make sure that the vSphere Web Client has a valid SAML token, then checks the user's credentials against the configured identity source, such as Active Directory. If the user's credentials are successfully authenticated against the identity source, the service returns a token to the vSphere Web Client (step 3). This token represents the user from this point on. Next, the token is passed to vCenter Server (step 4), which checks with the vCenter Single Sign-On service to make sure the token is valid and hasn't expired (step 5). Finally, the token is returned to vCenter Server and the user is allowed access to the objects they have permissions to utilize (step 6).

This methodology provides benefits beyond centralized administration and a simplified login process. Consider a situation where a vSphere infrastructure consists of multiple sites (Figure 2.11).

With SSO, access to each site and their related components is restricted to a single access point, represented in the graphic as the gate into the domain. Authentication data for the domain is shared between the domain and each of the sites. Furthermore, instead of login and password information being passed around, the token is used. This results in a more tightly controlled, more secure environment.

vCenter Single Sign-On actually consists of multiple components, as shown in Figure 2.12.

The first of these components is the Security Token Service (STS). This service issues tokens, or more specifically, Security Assertion Markup Language (SAML) tokens. These are the tokens that represent the identity of a user once the user has been authenticated against a supported identity source. Once a user has a token, the token allows the user to access any vCenter service, including VMware and thirdparty extensions, without authenticating again to each service. All tokens are signed with a signing certificate, which is stored on disk along with the certificate for the service itself. Next is the Administration Service, shown here running as a service within the STS. This service allows users with administrator privileges to configure the vCenter Single Sign-On server and manage users and groups from the vSphere Web Client. By default, the only admin user is administrator@vsphere.local, but beginning with vSphere 6.0, you can change the vSphere domain during installation. The next component is the VMware Directory Service (vmdir). This service is a multi-tenanted, multi-mastered directory service that provides an LDAP directory that, effective with vSphere 6.0, stores both Single Sign-On and certificate information. The information stored in the directory is propagated to other SSO instances, should they exist. The service uses port 389 and can also use port 11711 to communicate with earlier vSphere versions. The final component is the Identity Management Service. This service handles identity sources and is used to respond to STS authentication requests by communicating with LDAP or Active Directory.

Platform Services Controller

Services such as vCenter Single Sign-On, licensing, and certificate management are pervasive throughout a typical vSphere infrastructure deployment. As a result, effective with vSphere 6.0, these services have been centralized to a component called the Platform Services Controller (PSC). Because these are required services, they are embedded with every installation of the vCenter Server Appliance and vCenter Server for Windows. However, these services are also critical to the infrastructure, so vSphere also provides an external PSC that can be deployed to be highly available. There are advantages and disadvantages to using an embedded or external PSC, which I will review here.

For small deployments it makes sense to use vCenter Server with the embedded Platform Services Controller, as shown in Figure 2.13. This is one of the simplest deployment methodologies, and because both components exist on the same virtual machine, licensing is reduced and management is simplified. Furthermore, some network-based issues that could occur due to connectivity or name resolution are eliminated in this type of installation. However, if you think the vSphere infrastructure might grow larger over time, keep in mind that you cannot join other vCenter servers or Platform Services Controllers to the vCenter Single Sign-On domain created on the embedded PSC. Fortunately, if the growth is unexpected and you need to change the deployment method, it is possible to convert to an external Platform Services Controller.

For larger deployments and/or highly available deployments, an external Platform Services Controller should be used, as shown in Figure 2.14. In this type of deployment, you have a choice of creating a new vCenter Single Sign-On domain or joining an existing domain. Joined PSC instances replicate data between each other and can even span multiple sites. Once the external Platform Services Controller has been deployed, multiple vCenter Server and/or vCenter Server Appliance instances can be registered with the PSC. Once registered, these vCenter Server instances assume the vCenter Single Sign-On site of the PSC and are connected in Enhanced Linked Mode. While you could point out that disadvantages of this deployment method include increased complexity and the need to monitor network connectivity, I would say that if you have a larger deployment or want a highly available deployment, you pretty much have to go this route. The one thing I would recommend is that if you have to separate out these services and you are going to introduce network complexity, you should just go to the next step and make the solution highly available.

A highly available deployment would require a minimum of two external Platform Services Controllers sitting behind a load balancer, as shown in Figure 2.15. The total number of PSC instances you can have is subject to change and should be verified in the current version of the Configurations Maximums guide. This type of deployment allows for automatic failover in the event one of the PSC instances stops responding, with the load being automatically redistributed among the remaining instances.

There are several other deployment types, but they are all just variations on the major themes shown here. In the end you will deploy a stand-alone model, an external model, or a highly available external model.

Configuring vCenter Single Sign-On

Once you have decided on a deployment model and deployed the PSC instances, you will need to configure vCenter Single Sign-On. The first step in configuring SSO is to configure an identity source. An identity source is a collection of user and group data stored in a database. With vCenter Single Sign-On, you can use Active Directory, OpenLDAP, or local access using the OS on the machine where SSO has been deployed. When configuring an identity source, it is possible to configure multiple identity sources and select which of these sources will be the default.

To configure an identity source, log in to the PSC instance either using the vSphere Web Client or by connecting directly to the PSC web interface. You must log in using an account that is a member of the vSphere Single Sign-On Administrators group. Next, navigate to the SSO configuration UI. Navigate to the Identity Sources tab and click the Identity Sources icon. From here, you can add one of four different types of identity sources:

• Active Directory (Integrated Windows Authentication)
• Active Directory as an LDAP Server
• OpenLDAP
• LocalOS

If you are using Active Directory and the virtual machine running the PSC instance is connected to the domain, select the Integrated Windows Authentication option. This option uses the AD configuration information on the virtual machine. If needed, you can choose the AD as an LDAP Server option, but you will be required to manually enter all of the AD information. The LocalOS option should only be used if there is no other identity source, and even then this option would quickly become difficult to manage and is not recommended. Also keep in mind that once this step is complete, users can be authenticated but will not have any access to any objects until permissions are set within vCenter Server

Configuring an identity source provides standard authentication into a vSphere infrastructure, but in some cases a deployment may call for stronger authentication. This can be accomplished using two-factor authentication, which was introduced starting with vSphere 6.0 Update 2. In order to use this type of authentication with vSphere, a plug-in is required. For vSphere 6.5 and up, use the Enhanced Authentication Plug-in. When using two-factor authentication, VMware supports Smart Card authentication and RSA SecurID authentication. With Smart Card authentication, a user swipes or inserts a physical card, typically a Common Access Card (CAC), into a card reader attached to the machine they log in to. The card, along with a PIN code, is matched against a smart card certificate, allowing the user to log in. RSA SecurID authentication requires a correctly configured RSA Authentication Manager and a token, which can be either a hardware token or delivered using a SmartPhone app. Only a user with the correct username and token number can successfully log in. Examples of the physical components used in two-factor authentication are shown in Figure 2.16.

The next step in configuring vCenter Server Single Sign-On is to replace the STS Signing Certificate, if required by your organization. By default, this is a self-signed certificate generated by the VMware Certificate Authority (VMCA), which resides on the PSC. If your organization's security policy prevents the use of self-signed certificates, you can configure the VMCA to act as a subordinate CA, or you can bypass it entirely. In these cases, you will be using a certificate generated by an in-house or commercial certificate authority. Once you have generated the certificate, you use the certificate-manager utility (see Figure 2.17) to replace the default certificate with the custom CA certificate.

The final step in configuring vCenter Server Single Sign-On is setting the policies that will be used in the environment. There are three policies that must be configured: the Password policy, the Lockout policy, and the Token policy. Keep in mind that these policies are only used with the SSO accounts and do not have any impact on accounts added by integrating an identity source like Active Directory.

The default vCenter SSO password policy is set to expire passwords after 90 days. This setting can be changed, along with additional parameters, including password reuse and minimum and maximum length and character requirements.

The vCenter SSO lockout policy is designed to lock out a user who enters incorrect login information. By default, a user is locked out if they enter invalid information 5 times within 3 minutes, and the account is reset after a 5-minute lockout period. This behavior can be changed by altering any of these three variables.

Finally, the vCenter SSO token policy specifies how tokens behave. In many cases, you may want to adjust these settings to conform to your organization's security standards. These settings include clock tolerance, maximum token renewal and delegation counts, and maximum bearer token and holder-of-key token lifetime.

Securing Virtual Machines

The final critical step in securing a vSphere infrastructure is the hardening and securing of virtual machines. A virtual machine should be secured in much the same way a physical server would, and the operating system running on a virtual machine is subject to the same security risks as an operating system running on a physical machine. The following sections will primarily focus on the steps needed to harden the virtual machine itself. In most cases, an organization already has a methodology for patching and securing the various operating systems running in its infrastructure, and those steps can be directly applied to the virtual environment.

Secure Boot

First, let's take a look at any bootable virtual machines that might exist in a vSphere deployment. Bootable virtual machines can be hardened using UEFI Secure Boot. UEFI Secure Boot is a security standard designed to ensure that a system boots using only trusted software. This is validated using certificate signing against the bootloader, the OS kernel, and OS drivers. vSphere 6 virtual machines also include certificates for Windows and Linux bootloaders and for booting ESXi inside a VM. To support UEFI Secure Boot, virtual machines must be running VMware Tools version 10.1 or later.

To enable Secure Boot, first verify that the virtual machine's OS supports UEFI boot, that you are using EFI firmware, and that the VM has been built on virtual hardware version 13 or later. Next, while the VM is powered down, enable UEFI Secure Boot by editing the VM's settings using the vSphere Web Client and clicking the Enable Secure Boot check box. Please note that you must have VirtualMachine.Config.Settings privileges in order to modify this setting.

Virtual Machine Encryption

When we look at securing a virtual machine, one of the key concepts to remember is that a virtual machine exists as a series of files. Someone with the proper level of access could make a copy of these files, place them in another vSphere infrastructure, and bring up the virtual machine, potentially allowing access to sensitive data. In fact, it wouldn't even be necessary to boot up the virtual machine if the guest OS is known, since one could simply attach the VMDK file to a virtual machine running the same OS. Another similar concern appears when a virtual machine is migrated from one storage location to another, since at that time the entire contents of the virtual machine traverses the network and is vulnerable to anyone that could tap into the network during this operation.

Until the release of vSphere 6.5, these security challenges were mitigated through the use of various encryption methods, each of which came with its own challenges. Take, for example, the use of inguest encryption. This methodology involves using a custom preboot partition that uses keys to verify authenticity prior to allowing the encrypted partition to boot. There are two main issues with this method. First, it is guest-OS specific and most vSphere infrastructures run virtual machines with a variety of operating systems. Second, this method injects a high degree of overhead into the management process.

As an alternative, it is possible to use infrastructure-based encryption, either using self-encrypting drives (SEDs) or deploying encryption at the storage array level or even the fabric level. Unfortunately, when using SEDs or storage array level encryption, data still traverses the network as plain text. Fabric level encryption solves this problem but introduces potential portability issues. And in all of these cases, specific hardware is required.

Effective with vSphere 6.5, these issues are largely mitigated. That's because vSphere 6.5 introduced virtual machine encryption. vSphere's virtual machine encryption is centrally managed through vCenter, requires no specific hardware, and is not tied to any specific guest operating system. In addition, because data is encrypted at the virtual machine, any VM traffic that traverses the network is also encrypted. When a virtual machine is encrypted, its VMDK files, snapshot files, core dump files, swap files, and NVRAM are encrypted. Some files, such as the VM's config file, log files, and the virtual disk descriptor files, are not encrypted but do not contain any sensitive data. It is important to note that most encryption has a certain level of resource overhead. When you're enabling virtual machine encryption on a VM, additional storage capacity is consumed. This is particularly true when encrypting an existing unencrypted VM, which requires double the capacity of the VM. VMware recommends encrypting VMs at creation, whenever possible.

There are three main components involved in virtual machine encryption: the vCenter Server, the ESXi host(s) running the encrypted or to-be-encrypted virtual machines, and a Key Management Server (KMS). It is important to note that VMware does not supply a KMS. Instead, VMware provides a list of supported KMS products from a number of security and cloud vendors. It is the role of the KMS to generate and provide keys to vCenter Server, which are then handed off to the ESXi host running the encrypted virtual machine. The vCenter Server centralizes a number of administrative features, including who is allowed to access the KMS. Because of this, an added layer of security would be to ensure that the KMS and the vCenter Server are never running on the same physical machine. The vCenter Server also provides events that can assist with auditing and adds storage policies that can be used to control encryption on the virtual machines and disks. The ESXi host running the virtual machine is responsible for the actual encryption, which ensures that any data leaving the host and traversing the network is encrypted. Each ESXi host has a host encryption mode setting, which is typically enabled by default. The current setting can be checked and/or modified using the vSphere Web Client. The steps and flow involved in encrypting a virtual machine are shown in Figure 2.18.

One final piece to discuss regarding encryption is encrypted vMotion. The first thing to know is that if you are migrating an encrypted virtual machine using vMotion, the migration is encrypted by default and no additional action is required. The encryption used during migration ensures that data transmitted across the network is encrypted and not sent in plain text. But what if you wanted to migrate a virtual machine that is not encrypted but you want the migration activity to be encrypted? The good news is that this is entirely possible in vSphere and can be easily configured by editing the settings of the unencrypted VM. There are three settings: Disabled, Opportunistic, and Required. By default, unencrypted virtual machines are set to Opportunistic, which means that they will use encrypted vMotion as long as both the source and destination ESXi hosts support it. This setting can be changed to Disabled, in which case vMotion can be used but is not encrypted. The other option is Required, which requires encrypted vMotion and will not allow a vMotion to be performed if encrypted vMotion cannot be used.

Virtual Machine Hardening

One step in securing virtual machines in a vSphere infrastructure is hardening the VM by tightening the controls governing various virtual machine activities. Tightening these controls places limits on securitysensitive actions so that only certain individuals can perform them. One way to do this would be to create a group (something like Secure Admins) and then assign privileges governing sensitive activities to this group while ensuring that these privileges are not present in any other group, or explicitly assigned to a user. A simple way to do this for administrators that do not need guest access would be to create a group (like Admins without Guest Access) and deselect All Privileges.Virtual machine.Guest Operations. Many of the more sensitive actions fall into a set of privileges known as Virtual Machine Interaction privileges. The first activity that falls into this set of privileges is the installation of VMware Tools. In order to install VMware Tools, the administrator must have the Virtual machine.Interaction.VMware Tools install privilege. Tightening this control ensures that VMware Tools is installed only where needed and makes it easier to audit this activity. Also, the installation of VMware Tools enables some security-sensitive activities. Restricting the activity can help ensure that the admins performing the installations can follow up the install by configuring the usage of the activities enabled by VMware Tools. Other privileges in this group that may need to be limited are console interaction, drag and drop of files between the VM and a remote client, and the ability to perform wipe or shrink operations on a virtual machine.

The next step in hardening a virtual machine is to disable any unnecessary functionality in the VM. Unneeded services or devices on a virtual machine are potential vectors for attack. Removing these services and devices reduces the attack surface. Begin by removing any unneeded virtual hardware devices, such as serial ports, parallel ports, CD/DVD drives, network adapters, etc. In the event that one or more of these devices cannot be removed from the virtual machine, VMware recommends that the virtual machine be modified to prevent users from changing the device status. This can be done by editing the VM and adding the settings shown in Figure 2.19.

Next, remove any unused or unexposed features. These include unused display features (like 3D functionality), features needed only when running a VM on Workstation or Fusion, and the HGFS file transfer capability. While the first two of these vectors are fairly selfexplanatory, HGFS requires further explanation. HGFS stands for Host Guest File System, which is used for automated VMware Tools upgrades and some VIX commands. However, it also presents a vector that could potentially be used to transfer files to and from the guest OS. This particular feature should be evaluated by your security team because the efficiencies gained from automated upgrades may outweigh the potential security concern.

Another security concern is the ability to copy and paste data between the guest OS in a virtual machine and the remote console. In fact, the threat with this feature is high enough that this functionality is disabled by default. This is because not only could sensitive information be copied out of a virtual machine, but when the console window gains focus during the operation, processes running in the VM and even nonprivileged users could potentially access the clipboard. If sensitive information was copied to the clipboard before you used the console, now it's exposed. So even though the feature is disabled by default, VMware recommends explicitly disabling it by modifying the settings shown in Figure 2.20. Explicitly disabling this functionality ensures that any virtual machines that had enabled this feature are discovered and mitigated, and that the status of the feature can be audited moving forward.

When hardening a virtual machine, it is possible to modify a couple of settings and by doing so greatly reduce the possibility of a denial of service (DoS) attack. Since a virtual machine is essentially a collection of files, a DoS can occur if the files manage to consume all available space in the datastore they are located in or if a file becomes unavailable. There are two cases where this can happen that can be easily mitigated. The first case is related to the VMX file. Virtual machines send informational messages to the VMX file. This file starts out very small but can grow in size as these messages are added to the file. If a size limit was not enforced, it is possible for VMware Tools in the guest OS to send a large, continuous data stream to the host, which could cause the VMX file to consume all remaining space in the datastore it is located in, resulting in a DoS. Because of this, the file is limited to 1 MB by default. The file can be explicitly set to a certain size by editing the VM and adding the tools.setInfo.sizeLimit setting and selecting the appropriate size limit. The other activity that can lead to a DoS is virtual disk shrinking. This activity is typically used to recover unused space on a virtual disk, but repeated shrinking can cause the disk to become unavailable. This function can be disabled in a virtual machine by editing the VM and adding the parameters shown in Figure 2.21.

vSphere Network Security

A final area of concern regarding security is the network. Much of the configuration involved in securing a vSphere network surrounds the physical switch, VLANs, and firewalls. These components are covered in the networking section of this book. That being said, there is one area of security that is policy based and directly tied to vSphere Standard Switches and vSphere Distributed Switches, and we will focus on those settings here.

When working with vSphere Standard Switches or vSphere Distributed Switches, there are three security policies that can be configured. These are MAC address changes, Promiscuous mode, and Forged transmits. For vSphere Standard Switches, these policies can be configured on the VMkernel port group and on virtual machine port groups. For vSphere Distributed Switches, these policies can be configured on Distributed Port Groups and on the ports themselves. Each of these policies can be modified to help guard against several types of network-based attacks.

When a network adapter is created on a virtual machine, it is given a MAC address, referred to as the initial MAC address. Because this address is assigned to the virtual hardware itself, it cannot be modified by the guest OS. However, the guest OS uses its own address, referred to as the effective MAC address. While it is true that the guest OS typically assigns the initial MAC address to the effective MAC address, the guest OS can alter the effective MAC address at any time. In some cases, there is a legitimate need for the guest OS to do this, such as, for example, when using an iSCSI initiator or when working with Microsoft Network Load Balancing (NLB) in unicast mode. For this reason, the MAC address changes policy is set to Accept by default. However, this capability can also be used to impersonate a MAC address that would be recognized and authorized on the network, which could then allow a user to stage malicious attacks on devices on the network. The ability to impersonate a MAC address is also known as MAC spoofing. This capability can be disabled by setting the MAC address changes policy to Reject.

The second security policy, Forged transmits, works in concert with the MAC address changes policy. Both policies are there to ensure that the effective MAC address does not diverge from the initial MAC address, with the difference between the two policies centering on the direction of traffic. The MAC address changes policy is concerned with traffic coming into the virtual machine from the network, while the Forged transmits policy is concerned with traffic leaving the virtual machine destined for the network. If you do not have specific use cases for altering the effective MAC address on a virtual machine's adapter, you set both policies to Reject.

The final security policy to review is the Promiscuous mode policy. If this policy is set to Accept, the virtual machine is capable of seeing all of the network traffic on the wire. This would allow a user to capture potentially sensitive data destined for other devices. The only legitimate reason for enabling this policy is if the virtual machine is running network intrusion detection software and needs to see all of the traffic on the network. Even if this setting is intentionally enabled, keep in mind that leaving it enabled can impair network performance and should only be done during the time it is actively used.

Summary

Security is a key component of any system, and the more critical the system, the more secure it needs to be. A vSphere infrastructure typically hosts a large number of virtual machines, and since access to the vSphere platform grants access to those virtual machines, making sure vSphere is only accessed by authorized users is paramount.

There are several areas to cover when configuring vSphere security: permissions to users, securing the management components, identifying users, and encrypting virtual machines.

When granting permissions to users, you need to identify the privileges needed, group those into roles, and assign the roles appropriately in the infrastructure to the correct users. There are default roles included, some of which can be modified to fit your needs.

Hosts can be secured using Lockdown Mode to limit who can directly access them. You can also configure hosts to send logs to a syslog server and use advanced system settings for things like limiting the access protocols used. The vCenter can be secured by limiting user access, changing the password policies, and limiting access to the disks used by the server.

User access can be made more secure by using a central identity platform such as Active Directory. Configuring the Single-Sign On service to use an identity server prevents you from creating local users and provides easy user tracking across platforms.

Finally, virtual machine security can be enhanced with Secure Boot where the guest OS can be validated before booting and by using virtual machine encryption, which will prevent the virtual machine from being read if accessed outside its vCenter server.

Security is a priority for most environments and VMware provides several tools to ensure that your environment is secure.

Exam Essentials

Understand privileges and roles. Know that privileges are rights and they are collected in roles to be assigned to components for users. Be able to list and differentiate the default system and sample roles.

Know how to assign permissions. Be able to track permissions assigned in a hierarchy and the resulting effect on subordinate objects.

Know Lockdown Mode. Ensure that you know which mode does what and what types of access are limited and to whom.

Understand local users and passwords. Both ESXi hosts and VCSA use local users. Know the default local users and how to change the password settings.

Know how to configure Active Directory integrations. Be able to configure ESXi and SSO with Active Directory. Be aware of OpenLDAP and AD as an LDAP server as well.

Understand virtual machine security. Be able to explain Secure Boot and VM encryption. Also know how to harden a virtual machine.

Review Questions

1. What is the difference between a privilege and a role?

   1. A privilege is an action that can be taken in a vSphere environment; a role is a collection of privileges.
   2. A privilege is a duty a user has to perform as part of their job; a role is a collection of privileges.
   3. A privilege is an action that can be taken in a vSphere environment; a role is a duty a user has to perform as part of their job.
   4. A privilege is a duty a user has to perform as part of their job; a role is an action that can be taken in a vSphere environment.

2. What two types of roles are provided with vSphere by default? (Choose two.)

   1. System roles
   2. Sample roles
   3. Custom roles
   4. Host roles

3. A user belongs to two groups. One group has been granted the Virtual Machine Power User role and the other group has been granted the Read Only role. What permissions will this user have?

   1. A union of the privileges granted by both roles
   2. The most restrictive set of privileges granted by both roles
   3. The Virtual Machine Power User role
   4. The Read Only role

4. What two security concerns should be regularly audited on an ESXi host? (Choose two.)

   1. Exception users
   2. Datastore access
   3. SSH configuration
   4. Guest operations

5. What setting should be configured in order to ensure that logs on an ESXi host remain persistent, without impacting the output of any other diagnostic data?

   1. ScratchConfig.ScratchDir
   2. Syslog.global.logHost
   3. ScratchConfig. ConfiguredScratchLocation
   4. Syslog.global.logDir

6. What version of TLS (Transport Layer Security) does VMware recommend using with vSphere 6?

   1. 1.0
   2. 1.1
   3. 1.2
   4. 1.3

7. What does the enabling of Lockdown Mode using the Strict option change in regard to how the ESXi host is accessed?

   1. Users can only access the ESXi host directly from the console.
   2. Users can only access the ESXi host via vCenter Server.
   3. Users can only access the ESXi host if they are on the Exception Users list.
   4. Users can only access the ESXi host if they use SSH with a valid certificate.

8. Which vCenter Single Sign-On component stores both Single Sign-On and certificate information?

   1. Security Token Service (STS)
   2. Administration Service
   3. VMware Directory Service (vmdir)
   4. Identity Management Service

9. What are two major restrictions when using the embedded version of the Platform Services Controller? (Choose two.)

   1. Additional Platform Services Controllers cannot be joined to the vCenter Single Sign-On domain.
   2. Additional load balancers cannot be joined to the vCenter Single Sign-On domain.
   3. Additional vCenter Server instances cannot be joined to the vCenter Single Sign-On domain.
   4. Additional ESXi hosts cannot be joined to the vCenter Single Sign-On domain.

10. What is the minimum number of PSC instances required to create a highly available deployment?

    1. One
    2. Two
    3. Three
    4. Four

11. What role can be assigned to junior administrators to prevent them from accessing certain parts of the hierarchy?

    1. No Cryptography Administrator
    2. Read Only
    3. No Access
    4. Tagging Admin

12. What would prevent an administrator from being able to encrypt a virtual machine?

    1. The No Cryptography Administrator Role is assigned to the virtual machine.
    2. The virtual machine is version 14.
    3. No KMS server has been created.
    4. The No Cryptography Administrator Role is assigned to the administrator.

13. What service port by default would need manual intervention for firewall access for ESXi servers?

    1. 22 (SSH)
    2. 80 (HTTP)
    3. 902 (vSphere Web Client)
    4. 53 (DNS)

14. What two methods are required for nonroot DCUI access to a host with normal lockdown enabled? (Choose two.)

    1. A local user account
    2. A vCenter Server administrator account
    3. DCUI.Access configured
    4. Active Directory enabled on vCenter

15. What lockdown method can be used to block local console access for an ESXi host?

    1. Local
    2. Normal
    3. Embedded
    4. Strict

16. What two identity sources are available for Single-Sign On? (Choose two.)

    1. Active Directory (Integrated Windows Authentication)
    2. OpenLDAP
    3. LDAPS
    4. SAML

17. What would prevent virtual machine Secure Boot from being enabled?

    1. Virtual machine hardware version 12
    2. No operating system installed
    3. The No Cryptography Administrator role assigned to the administrator.
    4. No VMDK assigned

18. What two versions of Transport Layer Security (TLS) should be disabled with advanced settings? (Choose two.)

    1. 1.0
    2. 1.1
    3. 1.2
    4. 1.3