Centralized RBAC Missing from Virtualization Management Tools

As a delegate for Tech Field Day 6 in Boston, I was introduced to several virtualization and performance management tools from vKernel, NetApp, Solarwinds, Embotics, and a company still in stealth mode. With all these tools and products I noticed that each was not integrated into the roles and permissions of the underlying hypervisor management servers such as VMware vCenter, Citrix XenConsole, or Microsoft System Center.  This lack of integration implies that a user with one set of authorizations just needs to switch tools to gain a greater or even lesser set of authorizations. This is not a good security posture and in fact could devolve any security to non-existent.We already have issues with the base hypervisor and its many ways to access and control management functions. Now we add to it other management tools that add yet another layer and method to access and control management functions. This was addressed within my previous article, Security of Performance and Management tools within the Virtual Environment, but now there are some new wrinkles. The main premise of this previous post is that all activity that touches the management server of the hypervisor or the hypervisor directly should be proxied through something like HyTrust or some other tool. So let’s look at the new wrinkles created by the same tools.

Service Accounts

vKernel, Solarwinds, and NetApp all use service accounts to access the virtual environment details to gather data, which is pretty standard and normal. However, each of these tools uses a directory service such as Active Directory just for authentication, not for authorization. So since the service account must have minimally read-only access to the entire environment, a user who is restricted to just one set of VMs could login to these tools and see all the VMs, Networks, Storage Devices, etc. In this way these tools lack basic multi-tenant capabilities and allow for data leakage of oft-critical details about an environment.

The tools themselves are being marketed as administrator-only, but are starting to expand to provide portlet functionality so that their output could be mashed-up with other tools. Solarwinds has this feature built in, which I find to be quite handy. Even so, the authorization restrictions built into VMware vCenter and the other management tools are completely ignored.

Delegate Users

2011 06 14 07 36 18 300x132
Figure 1: vCenter Audit Trail Break


Tools such as Embotics and vKernel also offer the ability to perform tasks on your behalf through their interface, such as reducing memory and such. However, they do this using a delegate user. Because they have used a delegate user, you now have an audit trail correlation issue. While this correlation issue already existed within VMware vCenter and other management tools, it gets worse when you add yet another delegate user. Figure 1 shows the break in the audit trail when you just have one delegate user. You can audit data within vCenter but you just do not know who did what, when, where, or how on the host. The only recourse on a host is currently to correlate the logfiles between vCenter and the Host and if the time servers do not match this correlation is impossible.

2011 06 14 07 43 14 300x98
Figure 2: Audit Trail with HyTrust

As shown in Figure 2, even with HyTrust in the middle, once you hit vCenter the audit trail is one more broken. You can audit all actions within the vSphere Client but once a delegate user is in use within vCenter, the audit trail breaks down to the host, and you once more need to correlate timestamps within log files to determine who did what when where and how. Now there are SIEM solutions such as RSA Envision which can do this for you, it would be far better if there was some sort of tag that could be sent down with every command so that correlation is simply looking up the tag in the appropriate tool to find the real user. Unfortunately, no interface whether from VMware or a Third party supports this yet.

2011 06 14 07 40 47
Figure 3: VCommander and break in Auditing

The last issue with delegate users, per Figure 3,  is that if you now start using a tool that duplicates what vCenter does via a delegate user, you now have a broken audit trail from that tool, such as Embotics VCommander, already down to the host. You now have to correlate data across three systems ensuring of course that all three have the same time source, etc. Even with HyTrust involved when using Embotics VCommander, the audit trail will be broken before HyTrust is even as use, as HyTrust is still accessed via a delagate user.


In many cases, auditing may not be difficult, depending on the number of simultaneous actions that take place, however, when faced with a forensic study or compliance regulation that must determine who did what when where and how, such a broken audit trail makes it impossible. Tie this to the possibility of data leakage and destruction from tools having the incorrect authorizations and you end up with a system that could be heavily impacted with the possibility of no way to track back who did what when where and how. Not only would we be insecure but in violation of regulatory compliance.

I call on the tool vendors to work with the hypervisor vendors to solve this problem. There must be not only centralized authentication (which we have with directory services) but centralized authorizations in order for a multi-tenant environment to succeed.  In addition, we need to be concerned about tools that span hypervisors which complexes this quite a bit. We also need audit capability all the way down the stack so that we know beyond any shadow of a doubt who did what when where and how.

Additional Info: There is at least one feature request with VMware to address their hypervisor/vCenter interactions.


Share this Article:

The following two tabs change content below.
Edward Haletky
Edward L. Haletky, aka Texiwill, is the author of VMware vSphere(TM) and Virtual Infrastructure Security: Securing the Virtual Environment as well as VMware ESX and ESXi in the Enterprise: Planning Deployment of Virtualization Servers, 2nd Edition. Edward owns AstroArch Consulting, Inc., providing virtualization, security, network consulting and development and The Virtualization Practice where he is also an Analyst. Edward is the Moderator and Host of the Virtualization Security Podcast as well as a guru and moderator for the VMware Communities Forums, providing answers to security and configuration questions. Edward is working on new books on Virtualization. [All Papers/Publications...]
Edward Haletky

Latest posts by Edward Haletky (see all)

Related Posts:

Leave a Reply

6 Comments on "Centralized RBAC Missing from Virtualization Management Tools"

Sort by:   newest | oldest | most voted
5 years 2 months ago

Interesting read, Here recently we didnt do so well with out pen testing on the virtual environments we host. Security has always been by far the largest concern with going virtual anything. However, it seems often than not that this is an after thought. Even in my current position it’s still an after thought. People dont understand if your virtual environment is comprimised its not just one server they are getting access too. Its the entire virtual environment…..

5 years 2 months ago

Hello Chad,

I think that depends on the compromise but for Management and Performance Tools for the virtual environment this is definitely the case. I wrote about a method to aid with that a while back as well. I do not cover the proper defense in depth required either, which is absolutely required. There is quite a bit you can do today that you could not do even a year ago to improve overall security.

Boils down to including all this in the architecture from the beginning.

Best regards,

5 years 2 months ago

Check out DynamicOps. We actually take care of this piece as an operations virtualization layer which unifies all of these tools under a single, user-aware governance model.


5 years 2 months ago
Hello Chad, Many tools claim to do that such as Embotics, but all need to speak to VMware vCenter who at this time is on of the final arbiter of who has access to what. However, if I my view is from the virtualization host to determine who did what on that host, then all the delegate users do is make that a feat of correlation which is not necessarily 100%. All these are good tools, but they are really too far up the stack to contain 100% of the audit trail as well as contain 100% of all authorizations… Read more »
5 years 2 months ago
Edward brings up some interesting observations about the implementation of proprietary RBAC by numerous virtualization and cloud management vendors and the need for the industry (as a whole) to be aware of forensic study, audit and compliance. Embotics agrees with Edward that the industry needs to evolve over time and we look forward to participating in the evolution. It is important to highlight that most all vendors are quite frankly in the same boat, including VMware who have their own proprietary RBAC (see Feb 2011 Virtualization Security Podcast: http://www.talkshoe.com/talkshoe/web/talkCast.jsp?masterId=34217&cmd=tc’ defer=’defer) As with most product features, ISV implementations of RBAC are… Read more »
4 years 10 months ago

[…] Centralized RBAC Missing from Virtualization Management Tools (Edward Haletky) […]