5 ms·

Encryption in Transit in Google Cloud

182 points by crb 9y ago

crb 9y ago
Direct link to PDF version: https://cloud.google.com/security/encryption-in-transit/resources/encryption-in-transit-whitepaper.pdf https://cloud.google.com/security/encryption-in-transit/reso...
boulos 9y ago
This document has been a long-time coming, and finally lets us talk about the encryption we perform on your behalf when transiting outside our physical boundaries. There are lots of paths, but I think the diagram [1] captures it well. Edit: Of particular note is that if you have a VM in say us-central1 talking to another of your VMs in us-east1, we encrypt that traffic across regions (even though it's riding our backbone). Disclosure: I work on Google Cloud (and even sort of contributed to this). [1] https://cloud.google.com/images/security/whitepaper-transit-01.svg https://cloud.google.com/images/security/whitepaper-transit-...
- foobarbazetc 9y ago
  Any chance you guys will support dual RSA+ECC custom certs on the HTTPS load balancer at some point? :)
  - boulos 9y ago
    I've pinged the PM to ask. Send me an email or check back here :).
    - foobarbazetc 9y ago
      Holy moly, it’s actually possible right now! It wasn’t there before, but you can assign multiple certs to a front end now, and it works as you expect (tested with SSLLabs.com). Great, thanks! :)
- CPAhem 9y ago
  When are you going to support end-to-end encryption for consumer apps? We use Syncdocs https://syncdocs.com https://syncdocs.com to encrypt Google Drive, but it would be better to use an entirely Google soultion.
- rakoo 9y ago
  I believe this diagram (http://www.theblaze.com/wp-content/uploads/2014/06/NSA-brief-slide.png http://www.theblaze.com/wp-content/uploads/2014/06/NSA-brief...) is even more simple to understand
kkotak 9y ago
Can someone explain how this pertains to Firebase hosted and FB realtime DB apps built using Angular5?
- cobookman 9y ago
  All of firebase's APIs are encrypted. Firebase hosting also serves content over HTTPS and redirect all http requests to https.
- boulos 9y ago
  Sure. Firebase runs on top of Google Cloud. So if you say use Firebase Functions, that's a "Google Cloud Service" in the diagram [1] in the article. Similarly, Firestore is also a "Google Cloud Service", so all requests to it (from say your Firebase Function) are encrypted as well. Disclosure: I work on Google Cloud (but disclaimer: not on Firebase). [1] https://cloud.google.com/images/security/whitepaper-transit-01.svg https://cloud.google.com/images/security/whitepaper-transit-...
  - kkotak 9y ago
    Thanks @boulos. Appreciate it. I'm unclear on what encrypted at rest means. For example - I'd expect the data in Google cloud store to be encrypted (or have an option to be encrypted) so that if someone were to get access to our DB admin account, they won't be able to see the JSON data in plain text. The only way to see the data would be through API access which can be configured for ACL (and by Google cloud store so we can index and query data which is encrypted at rest).
    - kdecline 9y ago
      encrypted at rest here means that any data sitting on disk is encrypted. Probably ACLed to the service requiring it. For example, when bigquery writes to disk, it gets encrypted with a key that BQ only has access to.
    - boulos 9y ago
      Encryption at rest [1] protects against someone who has access to the encrypted bytes from not being able to decrypt it. That is, if someone got the raw bytes off our storage somehow, it's not useful to them. If someone has access to your account, then the storage system can't tell if it's you or not. Data in Datastore (and Firestore fwiw, that needs an update) is encrypted at rest, and today's paper discusses how it's also encrypted in transit between your app and the service. I don't believe Datastore supports Customer Supplied Encryption Keys [2] (yet) but that lets you have a key that even Google can't decrypt the data without you providing it. That's a pretty good way to separate permission from keys. Disclosure: I work on Google Cloud. [1] https://cloud.google.com/security/encryption-at-rest/default-encryption/ https://cloud.google.com/security/encryption-at-rest/default... [2] https://cloud.google.com/security/encryption-at-rest/customer-supplied-encryption-keys/ https://cloud.google.com/security/encryption-at-rest/custome...
theptip 9y ago
The key thing here for my use-case is this point (which took a lot of digging to uncover when I last dove into this a year or so ago): > Data in transit inside a physical boundary controlled by or on behalf of Google is generally authenticated but not necessarily encrypted. Previously I believe this was not explicitly called out, but this is very important for GKE! In the default configuration, Kubernetes can arbitrarily bounce Service traffic between nodes, since the cloud LB selects a node at random, and then the Service iptables rules redirect the traffic to a node which hosts a pod that backs the Service. So if your regulatory environment (or SLA) requires end-to-end encryption, you are not covered using GKE out of the box. Options I've found to resolve this: 1) TLS to-the-pod 2) Using source-IP-address-preservation to ensure that the Service doesn't reroute your traffic to another node. I'd really prefer if Google made this limitation a bit clearer in their GKE docs, since it's a major security gotcha, and took me a lot of digging to piece together. But it's definitely a big step forwards that the encryption policy is spelled out explicitly here.
- adamfeldman 9y ago
  Does this section on Istio apply to your use-case? > If you want to implement mutual authentication and encryption for workloads, you can use istio auth. Specifically, for a workload in Kubernetes, Istio auth allows a cluster-level CA to generate and distribute certificates, which are then used for pod-to-pod mutual Transport Layer Security (mTLS). https://cloud.google.com/security/encryption-in-transit/#service-to-service_and_vm-to-vm_encryption https://cloud.google.com/security/encryption-in-transit/#ser...
  - TheIronYuppie 9y ago
    That was our intent (though we can always be clearer). If your regulatory environment requires that level of encryption, you'll want to use something, like Istio, that provides pod-to-pod mTLS (likely via a proxy or service mesh or both). Disclosure: I work at Google on Kubeflow
  - theptip 9y ago
    My use-case is currently quite simple (very few services) and so getting a TLS cert into each pod is easy enough. (I use the cluster CA to manually provision certs for the small number of private services that I have, and Acme certs for all of my publicly accessible services). As I roll out more services I've definitely got my eye on Istio, since auto-provisioned mTLS certs will be very useful. It does seem a bit bleeding edge though; it's only on version 0.3.
fowl2 9y ago
I read "Encryption in Google Transit" for a second and was confused.

182 points by crb 9y ago

crb 9y ago

Direct link to PDF version: https://cloud.google.com/security/encryption-in-transit/resources/encryption-in-transit-whitepaper.pdf https://cloud.google.com/security/encryption-in-transit/reso...

boulos 9y ago

This document has been a long-time coming, and finally lets us talk about the encryption we perform on your behalf when transiting outside our physical boundaries. There are lots of paths, but I think the diagram [1] captures it well. Edit: Of particular note is that if you have a VM in say us-central1 talking to another of your VMs in us-east1, we encrypt that traffic across regions (even though it's riding our backbone). Disclosure: I work on Google Cloud (and even sort of contributed to this). [1] https://cloud.google.com/images/security/whitepaper-transit-01.svg https://cloud.google.com/images/security/whitepaper-transit-...

foobarbazetc 9y ago
Any chance you guys will support dual RSA+ECC custom certs on the HTTPS load balancer at some point? :)
- boulos 9y ago
  I've pinged the PM to ask. Send me an email or check back here :).
  - foobarbazetc 9y ago
    Holy moly, it’s actually possible right now! It wasn’t there before, but you can assign multiple certs to a front end now, and it works as you expect (tested with SSLLabs.com). Great, thanks! :)
CPAhem 9y ago
When are you going to support end-to-end encryption for consumer apps? We use Syncdocs https://syncdocs.com https://syncdocs.com to encrypt Google Drive, but it would be better to use an entirely Google soultion.
rakoo 9y ago
I believe this diagram (http://www.theblaze.com/wp-content/uploads/2014/06/NSA-brief-slide.png http://www.theblaze.com/wp-content/uploads/2014/06/NSA-brief...) is even more simple to understand

kkotak 9y ago

Can someone explain how this pertains to Firebase hosted and FB realtime DB apps built using Angular5?

cobookman 9y ago
All of firebase's APIs are encrypted. Firebase hosting also serves content over HTTPS and redirect all http requests to https.
boulos 9y ago
Sure. Firebase runs on top of Google Cloud. So if you say use Firebase Functions, that's a "Google Cloud Service" in the diagram [1] in the article. Similarly, Firestore is also a "Google Cloud Service", so all requests to it (from say your Firebase Function) are encrypted as well. Disclosure: I work on Google Cloud (but disclaimer: not on Firebase). [1] https://cloud.google.com/images/security/whitepaper-transit-01.svg https://cloud.google.com/images/security/whitepaper-transit-...
- kkotak 9y ago
  Thanks @boulos. Appreciate it. I'm unclear on what encrypted at rest means. For example - I'd expect the data in Google cloud store to be encrypted (or have an option to be encrypted) so that if someone were to get access to our DB admin account, they won't be able to see the JSON data in plain text. The only way to see the data would be through API access which can be configured for ACL (and by Google cloud store so we can index and query data which is encrypted at rest).
  - kdecline 9y ago
    encrypted at rest here means that any data sitting on disk is encrypted. Probably ACLed to the service requiring it. For example, when bigquery writes to disk, it gets encrypted with a key that BQ only has access to.
  - boulos 9y ago
    Encryption at rest [1] protects against someone who has access to the encrypted bytes from not being able to decrypt it. That is, if someone got the raw bytes off our storage somehow, it's not useful to them. If someone has access to your account, then the storage system can't tell if it's you or not. Data in Datastore (and Firestore fwiw, that needs an update) is encrypted at rest, and today's paper discusses how it's also encrypted in transit between your app and the service. I don't believe Datastore supports Customer Supplied Encryption Keys [2] (yet) but that lets you have a key that even Google can't decrypt the data without you providing it. That's a pretty good way to separate permission from keys. Disclosure: I work on Google Cloud. [1] https://cloud.google.com/security/encryption-at-rest/default-encryption/ https://cloud.google.com/security/encryption-at-rest/default... [2] https://cloud.google.com/security/encryption-at-rest/customer-supplied-encryption-keys/ https://cloud.google.com/security/encryption-at-rest/custome...

theptip 9y ago

The key thing here for my use-case is this point (which took a lot of digging to uncover when I last dove into this a year or so ago): > Data in transit inside a physical boundary controlled by or on behalf of Google is generally authenticated but not necessarily encrypted. Previously I believe this was not explicitly called out, but this is very important for GKE! In the default configuration, Kubernetes can arbitrarily bounce Service traffic between nodes, since the cloud LB selects a node at random, and then the Service iptables rules redirect the traffic to a node which hosts a pod that backs the Service. So if your regulatory environment (or SLA) requires end-to-end encryption, you are not covered using GKE out of the box. Options I've found to resolve this: 1) TLS to-the-pod 2) Using source-IP-address-preservation to ensure that the Service doesn't reroute your traffic to another node. I'd really prefer if Google made this limitation a bit clearer in their GKE docs, since it's a major security gotcha, and took me a lot of digging to piece together. But it's definitely a big step forwards that the encryption policy is spelled out explicitly here.

adamfeldman 9y ago
Does this section on Istio apply to your use-case? > If you want to implement mutual authentication and encryption for workloads, you can use istio auth. Specifically, for a workload in Kubernetes, Istio auth allows a cluster-level CA to generate and distribute certificates, which are then used for pod-to-pod mutual Transport Layer Security (mTLS). https://cloud.google.com/security/encryption-in-transit/#service-to-service_and_vm-to-vm_encryption https://cloud.google.com/security/encryption-in-transit/#ser...
- TheIronYuppie 9y ago
  That was our intent (though we can always be clearer). If your regulatory environment requires that level of encryption, you'll want to use something, like Istio, that provides pod-to-pod mTLS (likely via a proxy or service mesh or both). Disclosure: I work at Google on Kubeflow
- theptip 9y ago
  My use-case is currently quite simple (very few services) and so getting a TLS cert into each pod is easy enough. (I use the cluster CA to manually provision certs for the small number of private services that I have, and Acme certs for all of my publicly accessible services). As I roll out more services I've definitely got my eye on Istio, since auto-provisioned mTLS certs will be very useful. It does seem a bit bleeding edge though; it's only on version 0.3.

fowl2 9y ago

I read "Encryption in Google Transit" for a second and was confused.