A few quick hits this morning…
While on vacation last week I missed this post on ‘Virtual Stovepipes‘ from that I would like to share with you. I beleive it’s the first blog post by Dale Wickizer, CTO NetApp U.S. Public Sector. Dale always blows me away with his insight and continues to do so when dicussing his insights around IT resource sharing.
If you work in the federal space maybe you’d consider subscribing to our public sector blog
In addition, yesterday the Cisco, NetApp, VMware design guide for the SMT architecutre was published. A public link is available at Cisco (note it’s also posted in the NetApp Field Portal for partners).
Hi Vaughn — congrats on the Bycast acquisition this morning — good move!
Regarding NetApp’s work on secure multi-tenancy: we and others think it still leaves much to desire in being both “secure” and “multitenant”.
Problem #1 is that any tenant is completely at the mercy of the service provider regarding security measures. Based on the first version of the NTAP document, the SP had access to unprotected tenant data, config files, etc.
No visible way for any tenant to independently enforce or verify any level of protection, other than a “trust me, it’ll be OK”.
Yikes!!
Problem #2 was that while VMware could isolate shared resource usage, as could Cisco, the NetApp array doesn’t have significant resource isolation features using your “multistore” thingie. No real QoS isolation that we could find.
Put differently, there doesn’t appear to be *any* way to keep one tenant from consuming all of the storage I/O channel, processors, cache, etc. on a shared array, effectively denying services to other tenants.
So, while I’d agree that your solution provides some degree of security, and some degree of multi-tenancy, I’d be hard-pressed to market it as a serious “security multitenancy” solution.
It needs to get better at both, IMHO.
— Chuck
Chuck,
Thank you for your compliment on the Bycast acquisition and for the questions/concerns you raised above. You raise a couple of thought provoking issues, deserving of a response. Please bear with my feeble attempt at responding, starting with your first question.
In any high security environment a “defense-in-depth” approach is used. This generally consists of redundant or overlapping layers of security, from the core to the edge of the network. Each layer is designed to protect against certain threat scenarios. At the foundation of all of this is physical access security (secure enclosures/cages, badged entry, perimeter surveillance and alarms, dogs, armed guards, etc.)
By definition service providers are going to own the equipment running the services they provide, which means they are certainly going to have physical access to it.
If one were to set aside Secure Multi-Tenancy for a moment, wouldn’t your comments really apply to any environment that is going to be run from a hosting or service provider? Aren’t you really asking the following: Are the people who have physical access to the equipment used to house my data and run my business, people I can trust?
Obviously, that is a very important question one must consider before employing a service provider to begin with! If you can’t trust them, you probably shouldn’t be doing business with them!
Fortunately, in my world (U. S. Public Sector), we have a number of very trustworthy providers, including some with very impressive physical security (certified to DoD and national security standards and with personnel trained in DoD counter-terrorism).
Now, getting back to Secure Multi-Tenancy (SMT):
The separation enforced for each tenant, from the VMware server hypervisor layer, down through the Cisco Nexus network and in the NetApp storage, is strictly there to guard one tenant from another. (To make sure the children all play nice :^) It is not there to guard the tenants from the service provider.
Within each of those “virtual stovepipes”, separate IP spaces, with separate directory services and access control lists are used. Role based access controls are employed, allowing a separate administrator role for each tenant.
Service providers stake their reputations on the fact that these safeguards prevent their tenants from misbehaving. In fact, numerous service providers around the world already depend on various components of the SMT solution today. MultiStore, which provides the separation on the NetApp storage, has been running in ISPs and other providers since 2001.
Now to your second question:
If I understand your question correctly, you want to know how NetApp ensures that one tenant doesn’t hog all the resources, assuming that these “virtual stovepipes” are run on shared infrastructure. Is that correct? That part is very easy: NetApp has a workload management product that allows quality of service (QoS) for storage CPU, memory and I/O resources. The product is called FlexShare (http://www.netapp.com/us/products/platform-os/flexshare.html).
Thank you again for your thoughtful comments and questions. By the way, we are hiring if you are interested. :^)
@Chuck – thanks for the questions, you raise validate points around security. Suffice to say, this is a version 1.0 solution. Version 2.0 is right around the corner. care to share more thoughts at that time?
@Dale – Does any customer base have greater security needs than the U.S. Public Sector? Obviously that’s a rhetorical question. Thanks for helping Chuck and the readers. I believe Chuck is confusing secure and isolated client access with vendor enablement for client content security and privacy. I’m not suggest ting that these topics don’t overlap, but rather that tehy are separate.