kube-network-policies

kube-network-policies is a Linux userspace policy engine for Kubernetes operators who need both ordinary pod rules and administrative policy formats. It is a strong fit for self-hosted teams comfortable managing manifests, Helm releases, and policy CRDs; the main decision is whether its userspace traffic handling matches your policy scope.

Overview

The project intercepts packets with Linux NFQUEUE and nftables, evaluates them in userspace, and enforces Kubernetes network policy rules. It supports standard Kubernetes NetworkPolicy, AdminNetworkPolicy (ANP), and BaselineAdminNetworkPolicy (BANP), including egress control. That breadth makes it useful when namespace-level controls must coexist with cluster-wide administrative rules.

Installation is documented with raw Kubernetes manifests or Helm. The local development path uses KIND and requires Docker, KIND, and kubectl. ANP and BANP add a distinct operational step: the experimental Network Policy API CRDs must be installed before deploying an ANP-configured daemonset.

Key features

Selective packet capture

For active policies aimed at particular pods, kube-network-policies dynamically identifies those pods and captures their packets instead of diverting every packet on the node. In standard NetworkPolicy deployments, that can reduce unnecessary userspace processing and keeps the implementation focused on traffic that policy rules actually cover.

The optimization does not apply when ANP or BANP is enabled. Administrative policy mode diverts all node traffic to userspace for evaluation, so teams choosing those formats should weigh the broader policy model against the heavier interception behavior.

Policy formats and evaluation

The evaluation pipeline checks logging, Admin Network Policy, standard NetworkPolicy, Baseline Admin Network Policy, and then defaults to allowing traffic. This ordering gives administrative rules a defined place in the decision path, while still supporting conventional namespace and pod policy. ANP and CNP rules can match external domain names through an in-memory DNS cache of DNS A and AAAA responses.

Diagnostics and extension

Structured JSON logs provide machine-readable records for troubleshooting policy decisions, which is valuable when operators need to correlate enforcement with cluster events. The PolicyEvaluator plugin pipeline can be extended with custom validation logic, making the project more adaptable to organization-specific checks than a fixed policy evaluator.

Pricing

Open-source project — free (Kubernetes network policy implementation; install with raw manifests or Helm).

There is no paid tier, seat allowance, subscription renewal, or trial period. The Apache-2.0 license suits teams that want to run and adapt the software themselves. The trade-off is that deployment, upgrades, policy design, and operational support remain the operator’s responsibility; maintainers direct users to the Kubernetes #sig-network Slack channel and mailing list.

Platforms

kube-network-policies runs on Linux in self-hosted Kubernetes environments, with Kubernetes and KIND supported in the documented setup. It is a policy implementation rather than a CNI plugin, so teams should evaluate how it fits their existing cluster networking stack rather than treating it as a complete replacement for one.

Who it's for

Choose it if you operate Linux Kubernetes clusters and need standard NetworkPolicy together with ANP or BANP, selective capture for ordinary policy workloads, JSON troubleshooting logs, or an extensible evaluator pipeline. It is also appropriate for engineering teams that can install experimental CRDs and are comfortable with userspace packet processing.

Look elsewhere if you need a turnkey networking platform, a CNI plugin, or administrative policies without the all-node-traffic behavior that ANP and BANP introduce. The project is not an officially supported Google product and is not eligible for Google’s Open Source Software Vulnerability Rewards Program; vulnerability reporting follows Kubernetes security and disclosure guidance.

Pros and cons

• Pro: Three Kubernetes policy formats. Standard NetworkPolicy, ANP, and BANP cover both routine workload controls and administrative policy requirements.
• Pro: Selective interception for targeted pods. Standard policy deployments can avoid diverting unrelated traffic to userspace.
• Pro: Useful operator tooling. Structured JSON logs and an extensible PolicyEvaluator pipeline support troubleshooting and custom validation.
• Con: Admin policies change the performance trade-off. ANP or BANP disables selective capture and sends all node traffic through userspace.
• Con: Extra setup for ANP and BANP. Experimental Network Policy API CRDs must be installed before the configured daemonset.
• Con: Self-managed operations. There is no paid support tier, and the software is not an officially supported Google product.

Alternatives

Canal is a better fit when you want a free Apache-2.0 project with broader API and desktop-platform availability alongside Linux and self-hosting.

Calico Open Source suits teams seeking community maintenance, in-memory data retention, and unlimited clusters in a free package.

CNI Plugins is the choice for reference and example CNI network plugins rather than a userspace policy evaluator.

Flannel fits a general-purpose open-source Kubernetes networking project.

Antrea is preferable when you can run Open vSwitch’s kernel module on every Kubernetes node and want a broader Kubernetes networking option.

Cello CNI is aimed at Volcengine ECS deployments requiring Kubernetes and Helm 3.0.

DANM is a neutral alternative for always-free Kubernetes network management.

See the Container Networking Software category for additional options.

Verdict

kube-network-policies is a focused choice for Linux Kubernetes operators who need three Kubernetes policy formats, egress control, selective capture for standard policies, and extensible userspace evaluation. Choose it when those policy capabilities matter more than turnkey networking; look elsewhere if ANP or BANP’s all-node interception, experimental CRD setup, or self-managed support model is a poor fit.