Tuesday night, I attended a gathering of Open Source cloud API developers. We had a number of interesting discussions, but one topic in particular generated significant controversy. Should public cloud providers reach into the guest operating system to perform various functions?
I've always held that a public cloud provider should treat the border between the hypervisor and guest operating system as a sacred barrier that should never be breached. During our conversation, I found that a number of other developers disagreed. What launched the topic was a simple discussion on identity bootstrapping mechanisms.
With Amazon Web Services (AWS), your operating system calls out to a web service to retrieve root SSH keys and any other bootstrapping data. Nearly every other cloud, on the other hand, reaches in some way into the guest operating system and writes out bootstrapping data (like a password file) to your file system. The Rackspace Cloud even enables you to provide complete files to be written at instance launch.
While the two approaches provide the same end result—bootstrapped configuration on your guest OS root file system—they are philosophically very different. In particular, the AWS approach represents a strong commitment not to cross the hypervisor barrier into your operating system. They treat your OS is a black box into which they won't reach. They take care of the hypervisor; you control the operating system.
And control is the operative word here. When we move into the public cloud, we are choosing to give up control over elements of our infrastructure that ultimately don't matter to us. The things that don't matter are hardware, networks, connectivity, and virtualization systems. The things that matter are your data.
As long as a public cloud provider is making a commitment not to reach across the hypervisor into your operating system, you retain control over your data in spite of the loss of control over the underlying infrastructure. You can manage your own access to your systems, lock out your cloud provider, and encrypt your data using keys the cloud provider never has access to. Any breach of that barrier is a critical loss of control over your data.
It's not that I don't trust the other cloud vendors. In fact, I have a lot of faith in some of them—the Rackspace Cloud among them. Faith, however, doesn't stop a subpoena or other compelled breach of the hypervisor barrier. Any cloud provider who can reach across that barrier for good reasons can be compelled without your knowledge to reach across it for not-so-good reasons. It's not even a question of whether they want to or not—it's the fact that they would have to do it.
While I prefer the AWS approach, AWS is not entirely praiseworthy here. We don't have any idea what customizations they have made to Xen and what hidden tools might exist to reach into the guest OS. AWS is less than forthcoming in this area. There are, however, no publicly known mechanisms for doing so. Furthermore, AWS has been very consistent in avoiding architectural approaches that require reaching across the barrier.
In the end, it's simply much easier for an enterprise moving into the cloud to meet reasonable data control and management standards when the cloud provider doesn't reach into the operating system than when it does. Though this whole issue may appear to be a distinction without a difference, it's an issue that just might end up being a deciding factor when you're picking a cloud provider and are concerned about the control issues associated with public cloud computing.