5 ms·
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
by 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 agoDoes 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 agoThat 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 agoMy 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.
- jdc0589 9y agothis is a big deal for a lot of people. I was always under the impression (I'm pretty sure I had someone at GCP tell me at one point too) that basically all network communication was encrypted behind the scenes, even within your infrastructure. This is clearly not correct. I asked questions about this exact same thing during a deep dive on EKS at reInvent a couple weeks ago; unsurprisingly the same issue exists there.
- boulos 9y agoRight. Encryption in transit within a building at line rate (and more importantly low latency) is hard. To my knowledge, none of the providers do this currently, otherwise they'd be talking about it. This is us saying it's time to talk about it :). Disclosure: I work on Google Cloud.
- londons_explore 9y agoMilitary stuff uses "XOR the data with a secret keystream", which is zero latency (okay - more like 10 nanoseconds of latency), and can run arbitrarily fast. The only disadvantage is one has to use a stream cipher, and those have fallen out of favor lately...
- mehrdadn 9y agoIs generating a cryptographically secure secret stream that fast?
- namibj 9y agoIf you want to, sure.
- londons_explore 9y agoYou can do it fully in parallel. Imagine 1000 crypto units each producing 100 Mbps of key-stream. All on one ASIC. Then all you need is to interleave the stream and XOR with the data to encrypt your 100Gbps stream.
- deleted 9y ago[deleted]