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.<p>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).<p>Disclosure: I work on Google Cloud (and even sort of contributed to this).<p>[1] <a href="https://cloud.google.com/images/security/whitepaper-transit-01.svg" rel="nofollow">https://cloud.google.com/images/security/whitepaper-transit-...</a>
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):<p>> Data in transit inside a physical boundary controlled by or on behalf of Google is generally authenticated but not necessarily encrypted.<p>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.<p>So if your regulatory environment (or SLA) requires end-to-end encryption, you are not covered using GKE out of the box.<p>Options I've found to resolve this:<p>1) TLS to-the-pod<p>2) Using source-IP-address-preservation to ensure that the Service doesn't reroute your traffic to another node.<p>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.
Direct link to PDF version: <a href="https://cloud.google.com/security/encryption-in-transit/resources/encryption-in-transit-whitepaper.pdf" rel="nofollow">https://cloud.google.com/security/encryption-in-transit/reso...</a>