
Encryption in Transit in Google Cloud - crb
https://cloud.google.com/security/encryption-in-transit/
======
boulos
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-...](https://cloud.google.com/images/security/whitepaper-
transit-01.svg)

~~~
foobarbazetc
Any chance you guys will support dual RSA+ECC custom certs on the HTTPS load
balancer at some point? :)

~~~
boulos
I've pinged the PM to ask. Send me an email or check back here :).

~~~
foobarbazetc
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! :)

------
theptip
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
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/#ser...](https://cloud.google.com/security/encryption-in-
transit/#service-to-service_and_vm-to-vm_encryption)

~~~
TheIronYuppie
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

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

~~~
boulos
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-...](https://cloud.google.com/images/security/whitepaper-
transit-01.svg)

~~~
kkotak
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).

~~~
boulos
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...](https://cloud.google.com/security/encryption-at-rest/default-
encryption/) [2] [https://cloud.google.com/security/encryption-at-
rest/custome...](https://cloud.google.com/security/encryption-at-
rest/customer-supplied-encryption-keys/)

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

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

