kube-network-policies

kube-network-policies is a Linux userspace policy engine for Kubernetes operators who need both ordinary pod rules and cluster-wide administrative policy formats. It is strongest when selective capture can limit evaluation to affected pods; teams enabling ANP or BANP must accept all-node userspace processing and additional CRD setup.

Overview

The project intercepts traffic with Linux NFQUEUE and nftables, then evaluates it in userspace. It handles standard Kubernetes NetworkPolicy as well as AdminNetworkPolicy (ANP) and BaselineAdminNetworkPolicy (BANP), including egress control. That combination suits clusters seeking policy enforcement without adopting a full networking stack, but it places packet processing in a userspace daemon rather than a dedicated CNI plugin.

Deployment can use raw Kubernetes manifests or Helm. The documented local-development route uses KIND and requires Docker, KIND, and kubectl. ANP and BANP add a firm prerequisite: install the experimental Network Policy API CRDs before deploying the corresponding daemonset.

Key features

Selective packet capture

With active policies targeting particular pods, the implementation identifies those pods and captures their packets instead of intercepting every packet. For standard NetworkPolicy workloads, that can avoid unnecessary userspace evaluation and makes the design more attractive where only a subset of workloads needs enforcement.

The optimization disappears when ANP or BANP is enabled. In that mode, all traffic on every node is diverted to userspace for evaluation. Administrative policy support is therefore a capability gain with a substantial traffic-handling trade-off, especially for operators concerned about broad interception overhead.

Policy pipeline and matching

The evaluation order is explicit: logging, Admin Network Policy, standard NetworkPolicy, Baseline Admin Network Policy, and finally an allow decision. That ordering helps teams reason about which rule wins, while the default allow behavior makes an incomplete policy set permissive rather than implicitly restrictive.

ANP and CNP can match external domain names through an in-memory DNS cache containing DNS A and AAAA answers. Domain-based decisions depend on that cache, so this is best for environments prepared to account for DNS-derived matching rather than relying only on pod and IP selectors.

Diagnostics and extensibility

Structured JSON logs expose policy decisions in a form suited to centralized log analysis and troubleshooting. The PolicyEvaluator plugin pipeline can accept custom validation logic, giving teams a route to enforce organization-specific checks beyond the built-in formats. The project is licensed under Apache-2.0.

Pricing

There is no paid tier, subscription, seat quota, or trial period. The free plan is a practical fit for teams able to operate Kubernetes policy infrastructure themselves; it does not come with a commercial support entitlement. Maintainer contact is through 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 platform set. Docker, KIND, and kubectl are required for the local development setup. It is not a general desktop networking utility and is not presented as a CNI plugin.

Who it's for

Choose it when your cluster needs standard NetworkPolicy plus ANP or BANP, structured decision logs, or an extensible policy-evaluation pipeline. It also fits operators who value selective capture for standard policies and are comfortable managing manifests, Helm releases, and experimental policy CRDs.

Look elsewhere if you need a broader CNI and networking platform, a managed service, or a design that keeps interception selective while administrative policies are active. The all-node userspace path for ANP and BANP is the central operational constraint.

Pros and cons

Pros

• Three Kubernetes policy formats: standard NetworkPolicy, ANP, and BANP cover both workload-level and administrative rules.
• Selective capture for standard policies: packets from unrelated pods avoid interception when they are outside active policy targets.
• Operationally useful diagnostics: structured JSON logs support automated troubleshooting.
• Custom validation: the evaluator plugin pipeline can be extended with organization-specific logic.
• No license cost: the Apache-2.0 project is free to deploy.

Cons

• Administrative policies disable optimization: ANP or BANP sends all node traffic through userspace.
• Extra CRD dependency: ANP and BANP require the experimental Network Policy API CRDs before deployment.
• Linux and self-hosted scope: it does not target managed, cross-platform, or desktop use.
• No commercial plan: support is community-oriented through Kubernetes channels rather than a paid support tier.

Alternatives

Antrea is a better fit when you want a broader Kubernetes networking project and can provide an Open vSwitch kernel module on every node.

Calico Open Source suits teams seeking community-maintained networking with in-memory data retention and unlimited clusters.

Cilium is the alternative when an eBPF-oriented open-source platform for Linux, with kernel 5.10 or equivalent, matches your cluster.

Canal is worth choosing for a free Apache-2.0 option spanning API, Linux, macOS, and self-hosted environments.

Flannel is a straightforward free Apache 2.0 Kubernetes networking project when you need a general networking layer instead of this focused policy engine.

CNI Plugins is the reference collection to pick when you need example and reference CNI network plugins under Apache-2.0.

Cello CNI fits Volcengine ECS deployments that can meet its Kubernetes and Helm 3.0 requirements.

VMware Workstation Pro is a free Windows or Linux host virtualization choice, not a Kubernetes policy implementation.

See the Container Networking Software list for more options.

Verdict

kube-network-policies is a focused, free choice for Linux Kubernetes operators who need three Kubernetes policy formats, selective capture for standard rules, and extensible, structured evaluation. Choose it when you can operate userspace enforcement and, for ANP or BANP, accept experimental CRDs and all-node traffic diversion; choose a broader CNI project when those trade-offs or the self-hosted scope do not fit.