The vSphere 5 Security Guide has been released publicly in draft form for comment. There are a number of changes and enhancements and you should go through each to review the applicability to your environment. Here is one of the highlights of the new version from my perspective and links through to the documents. It’s hard work putting this hardening guide together so thanks to Charu, Ben, Grant and Kyle, and the rest of the VMware Team for all their hard work on this.
I think you’ll really like the new format. It’s now delivered in a spreadsheet which is much easier to use and include in other documents. I would encourage you to review the drafts and to provide feedback directly to VMware via the community threads linked below, where you can also download the hardening guide.
vSphere Hardening Guide: 4.1 and 5.0 comparison – Rev B
vSphere 5.0 Hardening Guide – Public Draft
Duncan Epping has also published an article on the release of the public draft available on Yellow-Bricks – vSphere 5.0 Hardening Guide public draft available.
William Lam has just updated his vSphere Security Hardening Script and it is available in his article vSphere Security Hardening Report Script for vSphere 5.
One of the most important changes in my opinion is the removal of the recommendation to disable the VIX API from each VM in the VM configuration. This change has been replaced by controls being recommended in vCenter Server that prevent unauthorized administrators from making use of the API, while still allowing it’s functionality where necessary. This is a good change that balances functionality with security, and I’m very pleased to see it.
You may remember that I recently commented about the VIX API impact on SRM in my article – vSphere Security Hardening Policy and SRM 5, and this was also picked up on by Tech Target in VMware SRM 5 encounters potential security conundrum. There is now no longer a conflict or conundrum between the hardening guide and the requirements for SRM to re-IP VM’s during recovery. The use of the VIX API can be restricted to the SRM Service Account only, so that only this account, and not any human interactions (except for the supreme Administrator) can call it. It can further be restricted to only the VM’s that require SRM to change their IP’s during recovery, by choosing where to apply the permissions. This makes it very easy to audit.
I was fortunate to be able to provide input into parts of the hardening guide while in ‘beta’ effectively, and I will be providing further feedback on the public draft. From my perspective I think it should include more recommendations regarding SSL certificates. I think SSL Certs, given the importance and difficulty, needs a bit more of a mention, especially around expiry and validity checking.
William Lam at virtuallyGhetto has written a couple of very useful blogs on the topic of SSL Certificates that you may like to review. I hope that the recommendation to check expiry makes it into the final version of the hardening guide. If you want a way to fully manage the certificate lifecycle and replace certs automatically then you’ll want to check out vCert Manager – Changing VMware SSL Certs Made Easy.
Extracting SSL Thumbprint from ESXi – virtuallyGhetto
Automating SSL Certificate Expiry Validation for vCenter Server + ESX(i) Hosts – virtuallyGhetto
This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com, by Michael Webster +. Copyright © 2012 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.
[…] things are possibilities at all times. This is why VMware goes to a lot of effort to produce the Security Hardening Guides and putting their software through Common Criteria Certification and other Security Tests, and […]
[…] the important changes in the new hardening guide vs the vSphere 4.1 hardening guide in my article vSphere 5 Security Hardening Guide – Public Draft. I would encourage you to review that article if you haven’t already as the points are still […]