Aviatrix Kubernetes Firewall vs kube-network-policies

Aviatrix Kubernetes Firewall governs traffic entering, leaving, and moving between Kubernetes workloads across clusters and environments. It applies Zero Trust controls at the cloud network layer, outside Kubernetes clusters, so deployment does not require sidecars, agents, CNI replacement, or application changes. Policies can target pods, namespaces, services, and labels using Kubernetes-native identities. A centralized control plane manages policy across multicloud and multicluster environments, with automation options including Terraform, Kubernetes custom resource definitions, GitOps, and policies in Kubernetes manifests. Supported environments include AWS, Microsoft Azure, Google Cloud, and on-premises deployments, including EKS, AKS, and GKE. The product offers traffic visibility, observability, and anomaly detection, along with distributed firewalling, threat prevention, URL filtering, egress control, micro-segmentation, TLS decryption, DNS firewalling, and advanced NAT for overlapping address ranges. It can use a shared security model for containerized and legacy VM workloads. There is no free plan.

kube-network-policies is a free, open-source userspace implementation of Kubernetes network policies for Linux. It uses Linux NFQUEUE and nftables to capture and evaluate network traffic in userspace. The project supports standard Kubernetes NetworkPolicy, AdminNetworkPolicy (ANP) and BaselineAdminNetworkPolicy (BANP). It can identify packets from pods targeted by active policies and capture those selectively; enabling ANP or BANP disables that optimization and diverts all node traffic to userspace for evaluation. Its documented evaluation pipeline checks logging, Admin Network Policy, standard NetworkPolicy, Baseline Admin Network Policy, then allows traffic by default. ANP and CNP can match external domain names using an in-memory cache of DNS A and AAAA answers. Structured JSON logs aid troubleshooting, and the PolicyEvaluator plugin pipeline can take custom validation logic. Installation instructions cover raw Kubernetes manifests and Helm. The local development setup uses KIND and lists Docker, KIND and kubectl as prerequisites. ANP or BANP also require experimental Network Policy API CRDs before deployment. The project lists an Apache-2.0 license and directs users to the Kubernetes #sig-network Slack channel and mailing list for maintainers.