Implementing the HyTrust Appliance – Part 3

16 08 2011

Roles, Rules, & Constraints (Oh my.)

IMO, the flagship features of the HyTrust Appliance (HTA) are the additions to the default vCenter Server security mechanisms through a more granular set of access controls to the virtual environment.  As always, a layered approach to security is ideal, and use of the appliance provides just that. For more background, check out my previous posts on the HTA:

Implementing the HyTrust Appliance – Part 1 (deployment, configuration considerations)

Implementing the HyTrust Appliance – Part 2 (compliance templates, root password vaulting)

For those already using vCenter Server, the default roles provided by the HTA will seem very familiar.  In fact, most of them are almost identical to their counterpart roles in vCenter.  The HT_VMUser role, for example, provides the basic rights that you would expect for a user who only needs access to the console, and the rights to power on/off, the virtual machines they manage.  This role does not provide any additional access to other components of the virtual infrastructure, nor does it allow the users in it to make configuration changes to the virtual machines they control.

 

Rules pair Roles with specific users or Active Directory groups, essentially telling the HTA who can do what.  Assigning those Rules, either directly to a Policy Resource (any logical object in your environment) or through the use of  Labels or Rulesets, will fill in the rest of that equation and tell the HTA where those users can do their work.  This can all be a bit confusing to try and explain without concrete examples, so it’s probably time for a good use case that I ran into in my previous employer’s environment.

For the most part, the way that customers interact with the virtual real estate they rent in a multi-tenant model is fairly straightforward and falls into the normal “VM User”-type role.  So, I kept the default HT_VMUser role, which is linked to the vCenter Policy Resource object as shown in the pic below, along with many other default roles.

More access can be offered to customers who reside on dedicated storage or completely dedicated clusters.  The general model in these cases is that the virtualization experts run the hypervisor layer and delegate as much access to the customer as possible to deal with things like virtual machine management, datastore allocations, DRS pool maintenance, and alerting.  Obviously, granting some users rights to additional parts of the infrastructure exposes an additional element of risk.  However, as your virtualization services expand, you will find yourself looking for more ways to delegate features and infrastructure changes in a way that empowers customers without endangering them.

Let’s take networking for example.  Customers that have a good number of virtual machines may also have more than one network VLAN tagged to the physical hardware for their systems.  Without HyTrust, they would probably place a request to your team to facilitate this move; that ticket is assigned to someone, who then, depending on their workload, performs the 4 clicks of a mouse to move this VM to another network when they get the chance (perhaps even hours later depending on response time commitments).  This should be the perfect candidate for enabling self-service.

With the default vCenter Server role granularity available, if you open things up just enough to allow a user to move VMs between portgroups, you’ve just allowed them to move their VMs between *all* of the VLANs tagged to the host they reside on.  In a multi-tenant environment with dedicated networks, this is unacceptable and downright dangerous.

However, if you now require that the same user authenticates through the HTA as a gateway to the environment, you can establish additional Constraints to restrict this behavior.  In this case, let’s use the Constraint “Network Label Match,” which allows specification of what portgroups a virtual machine is allowed to be moved to.

Now, any Networks (portgroups in VMware-speak) that are labeled according to the selection in the rule constraint, are valid for the customer to move their virtual machines to. In the image above, this means that customers are only allowed to switch their VMs to portgroups labeled as “Untrusted,” preventing them from getting onto other networks, such as those of other customers. This can also be a good method for restricting other sysadmins from placing insecure VMs on production networks by limited the scope of where they are allowed to deploy those systems.

This has been just one example of how the HTA can be used to simultaneously grant your customer base (or even other sysadmins) additional privileges in the environment without sacrificing security or the safety of other systems.  Similar rules can be applied to storage provisioning, and even to using Constraints which actually provide users with different levels of access depending on where they authenticate from (trusted bastion hosts, less trusted servers, untrusted workstations, etc.).

In my experience, HyTrust has been quick to respond with updates to the HTA as new VMware ESX/ESXi and vCenter Server iterations come out, and is constantly looking for feedback to make their product even better. It’s past time to stop treating security in virtualization as a bolt-on feature and start thinking about it as critical component in your planning. Look for the HyTrust team at VMworld and give the HTA a whirl with their community edition:

http://info.hytrust.com/appliance.html

Main page: http://www.hytrust.com/

 

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.)

Advertisements

Actions

Information

One response

17 08 2011
Implementing the HyTrust Appliance – Part 1 « Notes from a Sysadmin

[…] Implementing the HyTrust Appliance – Part 3 (roles, rules, constraints, etc.) Advertisement GA_googleAddAttr("AdOpt", "1"); GA_googleAddAttr("Origin", "other"); GA_googleAddAttr("theme_bg", "ffffff"); GA_googleAddAttr("theme_border", "cccccc"); GA_googleAddAttr("theme_text", "000000"); GA_googleAddAttr("theme_link", "515151"); GA_googleAddAttr("theme_url", "f78b0c"); GA_googleAddAttr("LangId", "1"); GA_googleAddAttr("Autotag", "technology"); GA_googleAddAttr("Tag", "esxi"); GA_googleAddAttr("Tag", "hytrust"); GA_googleAddAttr("Tag", "security"); GA_googleAddAttr("Tag", "virtualcenter"); GA_googleAddAttr("Tag", "virtualization"); GA_googleAddAttr("Tag", "vmware"); GA_googleAddAttr("Tag", "vmware-vcenter"); GA_googleFillSlot("wpcom_below_post"); Like this:LikeOne blogger likes this post. […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s




%d bloggers like this: