Hey everyone! I'm interested in how you're managing DNS-based egress controls at scale in 2026. In our environment, which is multi-cloud and highly regulated, we really need support for DNS-based allowlists and wildcard entries (like *.example.com), and we're looking for consistent behavior across different cloud platforms.
We've explored various options:
- **Traditional non-transparent proxies** (like Squid and Envoy): We're trying to move away from this.
- **CNI solutions**: Cilium and similar tools are available, but the security boundary isn't acceptable for our info security needs.
- **Cloud-native tools** like Security Groups and Network Security Groups: These lack flexibility, especially with Kubernetes integration, and don't allow DNS rule configurations.
- **Third-party appliances**: These tend to be very expensive with many features we don't need.
Each solution seems to fall short in areas like operational overhead or cost or just don't offer proper DNS rule management. I remember back in 2023, I asked at a conference if people were doing egress filtering, and only a tiny fraction were. Is that a common trend, or do people just not see the value?
We're currently using Cilium for DNS and egress rules within the cluster, but with the risk that if someone gets root access on a node, it compromises everything, which is unacceptable for us. So, I'm curious:
- Do you still do egress filtering in 2026? How important are DNS rules for your work?
- What strategies do you use to maintain consistent rules across different environments?
- Do you implement egress filtering at the CNI level or with an external stack?
- If you've moved away from using a proxy, what alternatives have you adopted?
Bonus points for any lessons learned or things you wish you had done differently!
4 Answers
Running an OS like Talos can alleviate root compromise concerns by minimizing the attack surface. However, you're correct that protecting against root access is tricky; external solutions like firewalls or web proxies are necessary. You might look for solutions specifically designed for Kubernetes workloads for better management.
Have you looked into using DNS policies with Kyverno? It's great for managing Kubernetes resources, though it won't handle traffic control directly outside the cluster. Still, it can streamline some orchestration aspects for your network policies.
I'm a fan of Kyverno too, but I'm in the same boat—I'm looking for a solution that controls traffic egress outside the cluster.
We still do egress filtering, mainly for high-risk workloads. Keeping DNS allowlists manageable can be tough at scale, which is why many teams shy away unless it's a compliance requirement. We've ditched full proxies and use CNI DNS rules along with robust node hardening and monitoring—it's not flawless, but it works for us.
That makes sense! What CNI are you using? Cilium, Calico, or something that supports fully qualified domain names (FQDN)? Is it just a matter of lacking the right tools to enhance your egress filtering?
I've had my share of headaches with egress rules, and you've nailed the challenges. I agree that DNS-based filtering through CNI (like Cilium) is a solid starting point for defense. We maintain rule consistency using GitOps with Kustomize overlays. But, considering your concerns about root access, you might need to rethink your approach. Your safest bet could be a cloud-managed firewall or a third-party network virtual appliance (NVA). Yes, those can be pricey, but they ensure consistent rule application across environments. It's possible to minimize unused features in licensing to cut costs a bit, and you might find value in features you didn’t expect to use.
Thanks for the insights! We definitely have regulations to manage. And yeah, I see your point about weighing the costs versus the benefits of those third-party solutions.
I get what you're saying about the leap from in-cluster solutions to full NVAs. Did you manage to customize your NVA for just DNS egress? Or does the packaging force you to accept all those extra features?
Exactly what I'm hunting for! An external solution that understands Kubernetes workloads would be ideal.