It happened for our Windows infrastructure several years ago, and now it’s happening at the hardware virtualization layer – we’re too big for our britches and lack a solid methodology for monitoring, securing, and maintaining our vSphere systems as we continue to expand. Originally, I approached HyTrust regarding their HyTrust Appliance (HTA) primarily as a means to implement two-factor authentication for the virtual infrastructure via RSA SecureID. Our RSA/two-factor project is in limbo, but I quickly realized that HyTrust had much more to offer us than just two-factor authentication. Their implementation of host configuration templates alone has made it worth the purchase, not to mention the granular access policies and auditing, and root password vaulting (my favorite). Over a couple of posts, I hope to relay some of the implementation trials, tribulations, and successful milestones as we roll the HTA into production and start to get a better handle on our environment.
I’ll start by focusing on the installation of the HTA in our environment and how we went about evaluating the product to find the features we were most interested in utilizing. This isn’t intended to be an exhaustive review of the product; for that I suggest you visit the HyTrust site and peruse the available features or even try out the community edition of the appliance.
Installation, Initial Configuration, and Centralized Authentication
The installation of the appliance was pretty straightforward, and well documented in the HyTrust Appliance Installation Guide. Nonetheless, HyTrust sent out one of their systems engineers to help walk me through the initial setup during the proof-of-concept (POC). Early on we opted for the Mapped mode network configuration of the appliance due to concerns over the complexity of our network infrastructure in conjunction with Router mode. Mapped mode basically entails setting up extra IP addresses/hostnames for each device (ESX/ESXi or vCenter Server) that you want to manage. These frontend, or mapped, IPs are “owned” by the HTA, and users now point their vSphere Clients to the mapped IPs. Once they connect to the HTA on these IPs, it authenticates the user (against Active Directory in our case), and proxies, if authorized, their commands to the management IPs for the actual devices, after filtering and auditing the actions that those commands entail.
We ran into a couple of (easily resolved) quirks when switching from local to Active Directory (AD) authentication. Early on in the development environment, I found that I could only authenticate to (and through) the HTA using the Active Directory service account that the appliance uses to connect to our vCenter Server. During a site visit by some of the HyTrust developers, we were able to determine that the service account requires the “Read memberOf” property right on any account attempting to authenticate through it. It appears that this is probably a default right for user accounts in most 2K8 AD domains, ours is just *special.* Also, we run a two domain, single forest, AD structure with an empty root at the top. Since the HTA assumes that the service account accessing your vCenter Server lives in the root domain, this required me to obtain a policy exception to place the account in the root and get the appliance up and running.
Once we had networking and authentication squared away, it was time to play! I found the best way to do this was to come up with some use cases to identify the types of people who connect to our environment:
- Virtual infrastructure administrators
- Virtual machine users
- Private cluster administrators
- Billing/Manager-type users
Much like with vCenter, it’s important to match each use case with a role within the HTA. You can choose from a handful pre-built ones, or roll your own. One feature that immediately drew my attention was the notion of “Constraints,” which allows for even more granular permissioning. A constraint I immediately implemented on each rule I applied was the Client IP – this allowed the authorization of a user based on where they are connecting from. For example, our infrastructure administrators can now only manage the vCenter Server from a couple of very tightly controlled bastion hosts. Since these hosts require multiple forms of authentication, we are decreasing the likelihood of a compromised password having much of an impact in terms of the security of our infrastructure. While these same admins can still access VMs as a normal virtual machine user from anywhere on our network, any attempt to change critical parts of the infrastructure (such as Datacenter, Host, and vSwitch objects) from anywhere but the bastion hosts will be blocked – and all this without having to manage multiple accounts for each role type.
Obviously the roles implemented, along with their associated constraints and rules, will depend greatly on the environment and can be much more intricate and creative than what I have described so far. While the implementation of authorization policy using the HTA is fairly straightforward, it’s immediately obvious that a lot of thought needs to go into who can access what, and from where, before even getting started with the rule creation.
For next time: Host configuration templates and root password vaulting
All posts in this series:
Implementing the HyTrust Appliance – Part 1 (deployment, configuration considerations)
Implementing the HyTrust Appliance – Part 2 (compliance templates, root password vaulting)
Implementing the HyTrust Appliance – Part 3 (roles, rules, constraints, etc.)