Insights Into Google Compute Engine

snydeq writes "The Compute Engine announcement at Google I/O made it clear that Google intends to take Amazon EC2 head on. Michael Crandell, who has been testing out Compute Engine for some time now, divulges deeper insights into the nascent IaaS, which, although enticing, will have a long road ahead of it in eclipsing Amazon EC2. 'Even in this early stage, three major factors about Google Cloud stood out for Crandell. First was the way Google leveraged the use of its own private network to make its cloud resources uniformly accessible across the globe. ... Another key difference was boot times, which are both fast and consistent in Google's cloud. ... Third is encryption. Google offers at-rest encryption for all storage, whether it's local or attached over a network. 'Everything's automatically encrypted,' says Crandell, 'and it's encrypted outside the processing of the VM so there's no degradation of performance to get that feature.'"

Comments

The real question

[Anonymous Coward]

How long until Google cancels it?

Encryption detail?

[prestwich]

It's interesting them doing at-rest-encryption - now I wonder where the keys are stored and who has access to them?

Re:Encryption detail?

[PTBarnum]

I haven't seen any technical details yet, but I'd guess that the advantages of encryption would be (1) fewer people at Google will have access to the keys than to the data (2) an outside attacker who gets access to the raw data also needs to attack the key store (3) if by malice or mistake a disk is not properly wiped before being removed from the data center, it will be harder to get data off of it.

It's hard to see this as being worse than no encryption; even if it is easier to get the key than to get the encrypted data, you still need both to do anything with the data.

Re:Encryption detail?

[dolmant_php]

I attended the tech details IO session (https://developers.google.com/events/io/sessions/gooio2012/313/ - as of this writing, the video isn't up yet), and they said the encryption keys don't leave the server where the data resides.

Re:Encryption detail?

[MikeHalcrow]

I designed and implemented the disk encryption component of Google Compute Engine. (Trivia: I also created eCryptfs, which backs the home directory encryption in Ubuntu and provides local cache encryption in Chrome OS). PTBarnum outlined some good motivators for why cloud providers should encrypt all data-at-rest, even though they (necessarily) manage the key material. Additionally, it turns out that some customers' regulatory requirements can be met by encrypting all data as it crosses the guest-host VM boundary on its way to storage.

Re:Encryption detail?

[MikeHalcrow]

It's interesting them doing at-rest-encryption - now I wonder where the keys are stored and who has access to them?

The Google Compute Engine FAQ sheds some light on these details: https://developers.google.com/compute/docs/faq#disks

Can I retrieve ephemeral disk data if I have lost it?

No. All data written to ephemeral disk is encrypted with a key that is unique to the VM instance. By design, once a virtual machine terminates, all data on the ephemeral disk is lost.

Re:Encryption detail?

[joebeda3]

I'm the TL for Google Compute Engine and was the speaker at that talk. The answer is a little more subtle than that. We have two types of mountable disk -- ephemeral disk which stays on the physical machine and never leaves the machine and persistent disk that outlives an instance is written over the network.

For ephemeral disk, we generate the encryption key on the host machine and it only ever stays in memory. We are careful to control the code paths that see the key material.

For the persistent disk, by necessity, we need to manage the key as part of our overall virtual machine management infrastructure. We utilize some strongly audited and auditable systems to wrap the encryption keys and really lock down the users that have access to the unwrapping service. The name of the game here is to restrict the scope as much as possible.

BTW -- the video for the talk isn't up yet but I just shared the slides here: https://plus.google.com/110707185519531431463/posts/EfDCBjuPiPf.

Re:Encryption detail?

[uncqual]

(iDrive claims to be such a service.)

I tend to take claims iDrive makes with a grain of salt given their approach to "security" on the client machine. If, on a Windows iDrive installation, one looks at (for a typical installation) C:\Program Files\IDrive\UserName.ini, one finds a line of the form:

Encryption password=Vjku_Ku_Oa_Rcuuyqtf_CCCDDDEEE

Of course, not to worry, the password is well encrypted with a sophisticated algorithm. Yes. ROT-2 for alpha characters. Really.

So, this user's actual encryption password is: This_Is_My_Password_AAABBBCCC

I understand that some people want the convenience of not having to enter their encryption password (or, even, a password vault password) when using the service or at system boot or user logon, but there seems to be no way to 'opt out' of this convenience.

I assume the engineers at iDrive used ROT-2 as a joke instead of putting the encryption password in clear text. I'm not a humorless guy, but there's a few areas that I don't like joking about -- and security is one of them. Unfortunately, this unfunny joke decreases security because it slightly increases the chances that some users won't realize that their encryption password is sitting in (almost) cleartext on their local disk and they won't protect it well (most users, of course, would have no idea this file even exists).

Since iDrive seems to think that security is something to be "funny" and "cute" about, I question their general judgement on the topic. (Of course, it's possible that they are incompetent and don't do security reviews -- I suppose that's worse).

Google LAN

[roman_mir]

I found this to be an interesting piece of info

Even in this early stage, three major factors about Google Cloud stood out for Crandell. First was the way Google leveraged the use of its own private network to make its cloud resources uniformly accessible across the globe.

"When you create a Google Compute Engine account and use their resources," he said, "they provide a private network, a LAN of sorts that spans different regions. For example, if you set up an architecture to replicate a database from region A to region B, in the Google cloud, you don't need to traverse the public Internet to do it. You're using their private network."

How precisely that network is implemented (as its own private fiber or simply a very efficiently-routed VPN) is not disclosed by Google. But the key thing is that the whole structure is seen as a single network from a programming point of view. "This makes it easier if you're building cross-regional architectures," Crandall says. It's expected that Google will eventually expand Compute Engine to territories outside the United States.

- I really wonder if Google built (or bought) larges swaths of private infrastructure that is otherwise outside of the Internet, does anybody know?

Here is why I am wondering about it - Google as an ISP would then avoid outside costs to move its data, it's all internal costs, this turns Google into its own 'Internet' of sorts, Google only Internet.

That's why web neutrality is a nonsense concept from my perspective - if companies can build their own infrastructure, they can compete with each other and offer their own content at better speeds, but then Google could be an ISP that uses both, Google 'Internet' and external backend, but then on its own 'Internet', the content available from Google could be delivered at a higher priority and faster (and cheaper, because its internal costs, that can be managed easier).

By the way, there was a question in the story, asking why didn't Google provide this earlier. Well, maybe it tech wasn't ready or the business model wasn't there or maybe it's something to do with the government that wants to listen in on everything.

BTW., this is why such information should be made available, the speculation about the reasons for things like that could be worse than whatever the truth is.

Re:Google LAN

[Anonymous Coward]

Google's been buying dark fibers since at least 2005. So, they likely do have the capacity to do this in a lot of areas.

Re:Google LAN

[Trepidity]

That's why web neutrality is a nonsense concept from my perspective - if companies can build their own infrastructure

The problem is that it's really only a handful of Google-sized companies who can do so. The worry with net neutrality is that the traditional ability of smaller players to participate will be eroded, if you can no longer buy access to the internet as a leaf node via an ISP, and then have your traffic treated equally once you're on the network.

Yes, they do own massive fiber

[sirwired]

Google, in a very forward-thinking move, outright purchased massive quantities of laid fiber at rock-bottom prices after the telecom crash that followed the dot-com crash. There was quite a glut of capacity that nobody needed at the time and had no use for. They picked up years and years worth of bandwidth expansion without having to go through all the trouble and expense of actually laying that fiber.

Re:Uh

[ibsteve2u]

Yeah, Amazon does...and they'll let you download the "howto" for their cloud as free ebooks, too.

Re:Who is the troll?

[icebike]

Actually, its not a valid concern.

Google shuts down projects that have no clear path to making money, like Wave, Buzz and Others.

As far as I know none of these had any monitization mechanism other than pushing ads in your face.

Compute has a price schedule published right up front, and its about the twice the cost of the electricity to power a comparable computer, but with zero capital investment. Their data storage prices and bandwidth prices are also published, and are reasonable. You really couldn't afford to even put your legacy machines into production at these prices.

Clearly they expect this project to cover its own costs, and make use of excess capacity in their data centers.

Google can build a processor in house cheaper than Dell or any white-box company. With a gazillion of them on hand, they can provision them fast, swap them in when there is trouble, and they do it day in and day out. So chances are they are simply reselling the in house expertise they already have. None of this is going away any time soon, and they always need to maintain excess capacity for their own needs, so why not market that.

With a clear path to making money on this project baked in at the start, the only thing that would kill it is lack of customers. Hell I'm thinking of renting a couple cores just for playing around with.