Insights Into Google Compute Engine 80
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.'"
Re:Google LAN (Score:4, Informative)
Google's been buying dark fibers since at least 2005 [cnet.com]. So, they likely do have the capacity to do this in a lot of areas.
Re:Encryption detail? (Score:4, Informative)
It's interesting them doing at-rest-encryption - now I wonder where the keys are stored and who has access to them?
That is exactly the right question. If the encrypted data is worked on in the "cloud", the encryption keys have to be accessible to Google's servers. It's possible to have a remote backup service where the service doesn't have the keys. (iDrive claims to be such a service.) But if the data is processed in the "cloud", the keys are in there somewhere.
Yes, they do own massive fiber (Score:5, Informative)
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 (Score:5, Informative)
Re:Encryption detail? (Score:5, Informative)
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? (Score:5, Informative)
Re:Encryption detail? (Score:4, Informative)
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 [google.com]
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? (Score:5, Informative)
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 [google.com].
Re:how about I/O performance (Score:3, Informative)
but again, it would be performance with the data encryption, compared to non-encrypting EBS.
This is what RightScale, an early Google Compute Engine customer, had to say regarding encryption and performance: http://blog.rightscale.com/2012/06/28/rightscale-joins-google-compute-engine-for-launch-day/ [rightscale.com]
One very aggressive innovation that Google Compute Engine brings to cloud computing is encryption of data at rest, both for local ephemeral drives as well as for network attached drives. In the case of the network attached disks the encryption happens on the host before it is put on the network, so it’s also encrypted in transit. The encryption is on a per-project basis (Google’s term for an account). This is a big deal for security conscious organizations, especially those having regulatory or other mandates to encrypt all data at rest. On other clouds one solution is to run a loop-back crypto driver, but that eats into the VM’s performance. I’ve been benchmarking the Google Compute Engine disk performance (more on that in a future post) and the encryption doesn’t seem to have a noticeable impact on performance. Pretty awesome.
Re:Encryption detail? (Score:5, Informative)
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).