Authentication through vCenter Single Sign-On, and authorization through the vCenter Server permissions model, protects your vCenter Server system and associated services. You can modify the default behavior, and you can take steps to limit access to your environment.
As you protect your vSphere environment, consider that all services that are associated with the vCenter Server instances must be protected. In some environments, you might protect several vCenter Server instances.
vCenter Server Uses Encrypted Communication
By default ("out of the box"), all data communication between the vCenter Server system and the other vSphere components is encrypted. In some cases, depending on how you configure your environment, some traffic might be unencrypted. For example, you can configure unencrypted SMTP for email alerts and unencrypted SNMP for monitoring. DNS traffic is also unencrypted. vCenter Server listens on port 80 (TCP) and port 443 (TCP). Port 443 (TCP) is the industry-standard HTTPS (secure HTTP) port and uses TLS encryption for protection. See vSphere TLS Configuration. Port 80 (TCP) is the industry-standard HTTP port and does not use encryption. The purpose of port 80 is to redirect requests from port 80 to port 443, where they are secure.
Harden vCenter Server Systems
The first step in protecting your vCenter Server environment is hardening each machine on which vCenter Server or an associated service runs. Similar considerations apply to a physical machine or a virtual machine. Always install the latest security patches for your operating system and follow industry standard best practices to protect the host machine.
Learn About the vSphere Certificate Model
By default, the VMware Certificate Authority (VMCA) provisions each ESXi host and each machine in the environment with a certificate signed by VMCA. If your company policy requires it, you can change the default behavior. See the vSphere Authentication documentation for details.
For additional protection, explicitly remove expired or revoked certificates and failed installations.
Configure vCenter Single Sign-On
vCenter Server and associated services are protected by the vCenter Single Sign-On authentication framework. When you first install the software, you specify a password for the administrator of the vCenter Single Sign-On domain, administrator@vsphere.local by default. Only that domain is initially available as an identity source. You can add an external identity provider, such as Microsoft Active Directory Federation Services (AD FS), for federated authentication. You can add other identity sources, either Active Directory or LDAP, and set a default identity source. Users who can authenticate to one of those identity sources can view objects and perform tasks if they are authorized to do so. See the vSphere Authentication documentation for details.
Assign vCenter Server Roles to Named Users or Groups
For better logging, associate each permission that you give on an object with a named user or group and a predefined role or custom role. The vSphere permissions model allows great flexibility through multiple ways of authorizing users or groups. See Understanding Authorization in vSphere and Required vCenter Server Privileges for Common Tasks.
Restrict administrator privileges and the use of the administrator role. If possible, do not use the anonymous Administrator user.
Set up Precision Time Protocol or Network Time Protocol
Set up Precision Time Protocol (PTP) or Network Time Protocol (NTP) for each node in your environment. The vSphere certificate infrastructure requires an accurate time stamp and does not work correctly if the nodes are out of sync.
