VMware Engine security
Google Cloud VMware Engine has a shared responsibility model for security. Trusted security in the cloud is achieved through the shared responsibilities of customers and Google as a service provider. This matrix of responsibility provides higher security and eliminates single points of failure.
As part of the VMware Engine service, all customers get dedicated bare metal hosts with local attached disks that are physically isolated from other hardware. An ESXi hypervisor with vSAN runs on every node. The nodes are managed through customer dedicated VMware vCenter and NSX. Not sharing hardware between tenants provides an additional layer of isolation and security protection.
Customers keep control and ownership of their data. Stewardship of customer data is the responsibility of the customer.
Data protection for data at rest and data in transit within internal networks
Data at rest in the private cloud environment can be encrypted using vSAN software based encryption. vSAN encryption relies on external Key Management Solutions to store encryption keys.
VMware Engine enables vSAN data at rest encryption by default for any new private clouds deployed, with key management infrastructure managed by Google as part of the service. For details related to the default encryption model, see About vSAN encryption.
If the KMS must be managed by users, you can optionally deploy external key management infrastructure and configure it as a key provider in vCenter. For a list of validated KMS providers, see Supported vendors.
For data in transit, we expect applications to encrypt their network communication within internal network segments. vSphere supports encryption of data over the wire for vMotion traffic.
Data protection for data that is required to move through public networks
To protect data that moves through public networks, you can create IPsec and SSL VPN tunnels for your private clouds. Common encryption methods are supported, including 128-byte and 256-byte AES. Data in transit (including authentication, administrative access, and customer data) is encrypted with standard encryption mechanisms (SSH, TLS 1.2, and Secure RDP). Communication that transports sensitive information uses the standard encryption mechanisms.
If your service expires or is terminated, you are responsible for removing or deleting your data. Google will cooperate with you to delete or return all customer data as provided in the customer agreement, except to the extent that Google is required by applicable law to retain some or all of the personal data. If necessary to retain any personal data, Google will archive the data and implement reasonable measures to prevent the customer data from any further processing.
Your application data is located in the region you selected during the private cloud creation. The service does not change the location of the data on its own without specific customer action or trigger (for example, user-configured replication to a private cloud in a different Google Cloud region). However, if your use case requires, you can deploy your workloads across regions and configure replication and data migration between regions.
VMware Engine does not back up or archive customer application data that resides within VMware virtual machines. VMware Engine periodically backs up vCenter and NSX configuration. Prior to backup, all data is encrypted at the source management server (for example, vCenter) using VMware APIs. The encrypted backup data is transported and stored in Cloud Storage buckets.
Google Cloud VMware Engine relies on layers of network security.
The Google Cloud VMware Engine service runs within Google Cloud under the baseline network security provided by Google Cloud. This applies to both the VMware Engine application and the dedicated and private VMware environment. Google Cloud provides built-in protection against distributed denial-of-service (DDoS) attacks. VMware Engine also follows the defense-in-depth strategy for helping to secure the network edge by implementing security controls like firewall rules and NAT.
VMware Engine has logically separate Layer 2 networks that restrict access to your own internal networks in your private cloud environment. You can further protect your private cloud networks by using a firewall. The VMware Engine portal lets you define rules for EW and NS network traffic controls for all network traffic, including intra-private cloud traffic, inter-private cloud traffic, general traffic to the internet, and network traffic to the on-premises environment.
Vulnerability and patch management
Google is responsible for periodic security patching of managed VMware software (ESXi, vCenter, and NSX).
Identity and access management
You can authenticate to VMware Engine portal from Google Cloud using SSO. You grant access to users to access VMware Engine portal using IAM roles and permissions.
By default, VMware Engine creates a user account for you in the vCenter local domain of the private cloud. You can add new local users or configure the vCenter to use an existing identity source. For this, add either an existing on-premises identity source or a new identity source within the private cloud.
The default user has sufficient privileges to perform necessary day-to-day vCenter operations of the vCenter within the private cloud, but they do not have full administrator access to vCenter. If administrator access is temporarily required, you can elevate your privileges for a limited period of time while you complete the administrator tasks.
Some third-party tools and products used with your private cloud might require a user to have administrative privileges in vSphere. When you create a private cloud, VMware Engine also creates solution user accounts with administrative privileges that you can use with the third-party tools and products.