Aviatrix Blog

From KubeCon London: How Aviatrix Kubernetes Firewall Resonated with the Community

How KubeCon attendees responded to the Aviatrix Kubernetes Firewall's entrance into the Kubernetes ecosystem

Last week, I had the opportunity to represent Aviatrix at KubeCon London, where we showcased our new Aviatrix Kubernetes Firewall. The conference floor was buzzing with Kubernetes practitioners — platform administrators, DevOps engineers, developers, and security specialists all looking to improve their container environments. I wanted to share some insights from our conversations and what we learned about current Kubernetes security deployments in the wild.

 

Finding Our Place in the Kubernetes Ecosystem

Our goal at KubeCon was straightforward: We wanted to see how Kubernetes practitioners responded to our solution. I’m pleased to report that it did, particularly with platform administrators who immediately understood what we’re trying to accomplish.

What struck me most was how easily attendees grasped our concept. Many recognized that we’re filling a gap in their security architecture rather than competing with existing technologies. This “better-together” story really resonated.

When explaining our solution, we explained that it is complementary to existing Kubernetes technologies, using this analogy:

  • CNIs (like Cilium and Calico) function like network switches within Kubernetes
  • Service meshes (like Istio) operate like VPNs, providing secure tunnels
  • Aviatrix Kubernetes Firewall works as, well, an actual firewall — extending security beyond the cluster

 

This framing helped practitioners quickly understand where we fit in their stack.

 

What Makes Us Different: Kubernetes-Native Security

The differentiator that sparked the most interest was our deep integration with Kubernetes itself. We’re not just another firewall: we can read the Kubernetes API and dynamically apply security policies based on Kubernetes-native identities like pods, namespaces, and services.

This approach addresses a fundamental challenge for platform teams: traditional security relies on static policies based on IP addresses, which constantly change in Kubernetes environments. Our ability to adapt security policies to Kubernetes’ dynamic nature without manual intervention was a significant “aha moment” for many attendees.

 

The Use Cases That Resonated

Based on our KubeCon conversations, three use cases particularly resonated with the Kubernetes community:

 

1. Identity-Based Segmentation

Platform teams struggle with network segmentation that keeps pace with Kubernetes’ dynamic nature. Our ability to create security boundaries based on Kubernetes constructs (like namespaces and labels) rather than static IP addresses was immediately valuable to them.

As one platform admin told me, “We spend way too much time updating our security policies every time we redeploy or scale. Using Kubernetes identities would solve that headache.”

 

2. Egress Security

Many attendees expressed concerns about controlling outbound traffic from their Kubernetes workloads. Traditional solutions either lack visibility or require complex configurations. Our approach to intent-based egress security — allowing workloads to communicate only with authorized external endpoints — made immediate sense to security-focused attendees.

This is particularly important for teams dealing with compliance requirements like PCI-DSS or HIPAA, where preventing unauthorized data exfiltration is critical.

 

3. Policy as Code

The GitOps-friendly approach of defining security policies as code aligned perfectly with how modern platform teams operate. By integrating security into their existing CI/CD workflows, teams can maintain security without slowing down development.

One DevOps engineer mentioned, “If it doesn’t work with our GitOps pipeline, it doesn’t work for us — period.” Our approach of leveraging the Kubernetes Resource Model (KRM) for network security policy definitions hit the mark.

 

Bridging Worlds: Kubernetes and Traditional Infrastructure

A surprising insight from KubeCon was just how much on-premises Kubernetes is still deployed. While cloud-managed services like EKS, AKS, and GKE were prevalent, many enterprises maintain substantial on-prem Kubernetes footprints.

This hybrid reality creates challenges when traditional security tools don’t understand Kubernetes constructs, and Kubernetes-native tools don’t extend beyond the cluster. Our ability to unify security across:

  • Multiple Kubernetes clusters
  • Different cloud providers
  • On-premises environments
  • Traditional VM-based workloads

 

…addresses a gap that many attendees were actively struggling to fill.

 

The Multi-Cluster, Multicloud Reality

Another consistent theme in our conversations was the challenge of managing security across multiple clusters and cloud environments. Organizations aren’t just running one Kubernetes cluster — they’re running dozens or even hundreds across multiple environments.

Common challenges included:

 

Our approach of providing centralized, consistent security policy enforcement regardless of where workloads run directly addresses these pain points.

 

Moving Forward: What We Learned

KubeCon confirmed that our positioning as a complementary solution to CNIs and service meshes is the right approach. We’re not trying to replace the excellent in-cluster networking and security that tools like Cilium, Calico, and Istio provide. Instead, we extend security beyond the cluster boundary, connecting Kubernetes to the broader infrastructure world.

The event also reinforced that our focus on three key differentiators hits the mark:

  • Kubernetes-native security that understands pods, services, and namespaces
  • Multi-cluster, multicloud unified security
  • Simplified connectivity between Kubernetes and traditional workloads

 

As enterprises continue their Kubernetes journey, the need for security that bridges these worlds will only grow. We’re excited to be addressing this challenge and grateful for all the feedback from the KubeCon community.