This security demo showcases what can be accomplished with NSX in regards to compliance use case.
vSphere 6.5 is a turning point in VMware infrastructure security. What was mostly an afterthought by many IT folks only a few short years ago is now one of the top drivers of innovation for vSphere. Security has become a front and center focus of this release and I think you’ll like what we’ve come up with.
Our focus on security is manageability. If security is not easy to implement and manage then the benefit it may bring is offset. Security in a virtual infrastructure must be able to be done “at scale”. Managing 100’s or 1000’s of security “snowflakes” is something no IT manager wants to do. She/He doesn’t have the resources to do that. The key to security at scale is automation and in these new features you’ll see plenty of that.
Encryption of virtual machines is something that’s been on-going for years. But, in case you hadn’t noticed, it just hasn’t “taken off” because every solution has a negative operational impact. With vSphere 6.5 we are addressing that head on.
Encryption will be done in the hypervisor, “beneath” the virtual machine. As I/O comes out of the virtual disk controller in the VM it is immediately encrypted by a module in the kernel before being send to the kernel storage layer. Both VM Home files (VMX, snapshot, etc) and VMDK files are encrypted.
The advantages here are numerous.
- 1. Because encryption happens at the hypervisor level and not in the VM, the Guest OS and datastore type are not a factor. Encryption of the VM is agnostic.
- 2. Encryption is managed via policy. Application of the policy can be done to many VM’s, regardless of their Guest OS.
- 3. Encryption is not managed “within” the VM. This is a key differentiation to every other solution in the market today! There are no encryption “snowflakes”. You don’t have to monitor whether encryption is running in the VM and the keys are not contained in the VM’s memory.
- 4. Key Management is based on the industry standard, KMIP 1.1.
In vSphere vCenter is a KMIP client and works with a large number of KMIP 1.1 key managers. This brings choice and flexibility to customers. VM Keys do not persist in vCenter.
- 5. VM Encryption makes use of the latest hardware advances inherent in the CPU’s today. It leverages AES-NI for encryption.
This has been an ask for a long time and with 6.5 we deliver. What’s unique about vMotion encryption is that we are not encrypting the network. There are not certificates to manage or network settings to make.
The encryption happens on a per-VM level. Enabling vMotion encryption on a VM sets things in motion. When the VM is migrated, a randomly generated, one time use 256-bit key is generated by vCenter (it does not use the key manager for this key).
In addition, a 64-bit “Nonce” (an arbitrary number used only once in a crypto operation) is also generated. The encryption key and Nonce are packaged into the migration specification sent to both hosts. At that point all the VM vMotion data is encrypted with both the key and the Nonce, ensuring that communications can’t be used to replay the data.
vMotion encryption can be set on unencrypted VM’s and is always enforced on encrypted VM’s.
Secure Boot support
For vSphere 6.5 we are introducing Secure Boot support for virtual machines and for the ESXi hypervisor.
Note: If Secure Boot is enabled then you will not be able to forcibly install un-signed code on ESXi. This ensures that when Secure Boot is enabled that ESXi will only be running VMware digitally signed code.
Dramatically Simplified Experience
VIRTUAL MACHINE SECURE BOOT
For VM’s, SecureBoot is simple to enable. Your VM must be configured to use EFI firmware and then you enable Secure Boot with a checkbox. Note that if you turn on secure boot for a virtual machine, you can load only signed drivers into that virtual machine.
Secure Boot for Virtual Machines works with Windows or Linux.
vSphere logs have traditionally been focused on troubleshooting and not “security” or even “IT operations”. This changes in vSphere 6.5 with the introduction of enhanced logging. Gone are the days where you’ll make a significant change to a virtual machine and only get a log that says “VM has been reconfigured”.
We’ve enhanced the logs and made them “actionable” by now sending the complete vCenter event such as “VM Reconfigure” out via the syslog data stream. The events now contain what I like to call “actionable data”. What I mean by that rather than just getting a notice that “something” has changed you now get what changed, what it changed from and what it changed to. This is data that I can “take action” against.
In 6.5, you will get a descriptive log of the action. For example, if I add 4GB of memory to a VM that has 6GB today, I’ll see a log that tells me what the setting was and what the new setting is. In a security context, if you move a VM from the vSwitch labeled “PCI” to the vSwitch labeled “Non-PCI” you will get a clear log describing that change. See the image below for an example.
Solutions like VMware Log Insight will now have a lot more data to display and present but more importantly, more detailed messages mean you can create more prescriptive alerts and remediation’s. More informed solutions help make more informed critical datacenter decisions.
All of these features will have some level of automation available out of the gate. In future blog articles you’ll see PowerCLI examples for encrypting and decrypting VM’s, enabling Secure Boot for VM’s, setting Encrypted vMotion policies on a VM and a script I used to build an Enhanced Logging demo that you can tweak to show the benefits of Enhanced Logging in your own environment. All of the script example will be released on GitHub.
That’s it for vSphere 6.5 security! I hope you are as excited as I am about it! More details on each will be forthcoming in blogs and whitepapers. One thing to add is the vSphere 6.5 Security Hardening Guide. This will, as always, come out within 1 quarter after the GA of 6.5. I don’t anticipate major changes to the guide. Features like VM Encryption are not something you should expect in the hardening guide. For more information on the types of information that is now in the guide please reference this blog post.
As always, I appreciate your feedback and questions. You can reach out to me via email (mfoley at vmware dot com) or on Twitter @vspheresecurity or @mikefoley.
To learn more about vSphere 6.5, please see the following resources.
- Press Release
- What’s New in vSphere 6.5: vCenter Server
- What’s New in vSphere 6.5: Security
- What’s New in vSphere 6.5: Host & Resource Management and Operations
- What’s New in Virtual SAN 6.5
- vSphere 6.5 Product Page
Until now, there have really only been two enforcement points for security controls at our disposal: in the OS, and the Network. Each has their strengths and weaknesses. VMware NSX changes our options by opening up a new frontier for security, and the unique capabilities only a virtualized environment can offer.
In this video we explore how VMware NSX provides load balancing services with the Edge Services Gateway, how the ESG can be leveraged to provide services on demand, and allow you to pursue the DevOPs model with NSX. Additionally, we will take a look at a Tech Preview feature of NSX, the Distributed Load Balancer, why it matters, and what it means for you.
In this video we explore the feature set of the VMware NSX Edge Services Gateway, provide a topology example, and discuss how you can use the ESG in different ways to bring L3-L7 services into you cloud.
The VMware NSX Edge Services Gateway (ESG) is a virtual machine appliance which functions as a gateway and services appliance within the NSX platform. This video focuses on the routing capabilities of the ESG, as well as its interactions with the NSX Distributed Logical Router (DLR). The ESG is commonly used as a routing gateway at the boundary of an NSX environment, also known as a North – South gateway. Like the DLR, the ESG supports dynamic routing protocols in OSPF and BGP, as well as route redistribution. To provide additional architectural flexibility, up to 8 ESGs may peer with a single DLR in an Equal Cost Multi-Path (ECMP) configuration in order to maximize available bandwidth.
The Distributed Logical Router (DLR) in the VMware NSX platform provides an optimized and scalable way of handling East – West traffic within a data center. East – West traffic is the communication between workloads residing within the same data center, which is only increasing in modern data centers. In order to route between segments, traffic must be forwarded to a routing device, rather than directly to its destination. This non-optimal traffic flow is generally referred to as “hair pinning”.
The DLR component of the NSX platform prevents the “hair-pinning” by introducing an East – West routing element within the hypervisor kernel. Each host has a routing kernel module can perform routing between the segments its hosted virtual machines are connected to. The DLR is capable of advertising those connected networks to other routing devices by way of the OSPF and BGP dynamic routing protocols
Not all virtual networks are going to be connected to the physical world in the same way; some VXLAN logical switches may need to be directly layer 2 adjacent to an existing VLAN backed network, or need to reach a gateway or service interface that resides on a physically defined VLAN. These are some reasons VLAN to VXLAN bridge(s) may need to be implemented within VMware NSX. This is most common in the case of a migration effort to, or if a layer 2 domain containing workloads attached to both VXLAN and VLAN backed networks required.
The VMware NSX Distributed Firewall is unique in the market for its ability to operate at the vNIC level, in kernel in the hypervisor – giving you control you’ve never had before.