I thought about putting xDS in, but I worried it might be confusing for people who might not know the xDS specifics of Envoy. But now I'm second guessing it lol.
Cool! While in Kubernetes you have cilium that does basically the same thing, outside of Kubernetes I've been using explicit proxies to do this kind of thing, which requires applications to support http proxy. I could definitely see transitioning those workloads to using ebpf filters instead.
Any fundamental reason you can't allow/block individual ports, or just a design choice?
Neat. One issue I’ve encountered with lookup-based rules is the latency of updating the client’s name caches when records become stale. How do you handle that here, or does it need to be done in L7?
For looking up the IP or whether you are permitted for some host?
For the former you don't, it's just DNS. The local DNS server respects TTL, and is no more expensive than a normal DNS lookup. It just proxies it to take the resolved IPs and push them into the eBPF map.
For the latter, the default expectation is that you push the rules to the "Attachment", typically in the "SyncAck". If you need to make updates, you push down deltas (add/remove rule).
You _can_ do dynamic DNS resolution, and there you'll be paying either 1x or ~2x DNS depending on whether your control plane already knows the IPs.
The first sentence of the README is:
Which would make the title make much more sense!I agree.
I thought about putting xDS in, but I worried it might be confusing for people who might not know the xDS specifics of Envoy. But now I'm second guessing it lol.
Cool! While in Kubernetes you have cilium that does basically the same thing, outside of Kubernetes I've been using explicit proxies to do this kind of thing, which requires applications to support http proxy. I could definitely see transitioning those workloads to using ebpf filters instead.
Any fundamental reason you can't allow/block individual ports, or just a design choice?
Neat. One issue I’ve encountered with lookup-based rules is the latency of updating the client’s name caches when records become stale. How do you handle that here, or does it need to be done in L7?
For looking up the IP or whether you are permitted for some host?
For the former you don't, it's just DNS. The local DNS server respects TTL, and is no more expensive than a normal DNS lookup. It just proxies it to take the resolved IPs and push them into the eBPF map.
For the latter, the default expectation is that you push the rules to the "Attachment", typically in the "SyncAck". If you need to make updates, you push down deltas (add/remove rule).
You _can_ do dynamic DNS resolution, and there you'll be paying either 1x or ~2x DNS depending on whether your control plane already knows the IPs.
If you are running kubernetes, is there any reason to use this over cilium? What you are doing sounds very similar to what cilium does.
Maybe not, but we're not using k8s for our agent VMs