kubewarden/network-enforcer

Generate and enforce Kubernetes NetworkPolicies from observed workload traffic

Hosted by Cloud Native Computing Foundation · part of Linux Foundation

kubewarden/network-enforcer is written in Go and was last pushed on Oct 18, 2026. Data as of Oct 18, 15:29 UTC. Signed-in members get hourly updates — create a free account.

Summary Information

Updated 19 minutes ago

Type:ApplicationCategory(s):Kubernetes & Operators Network & Infrastructure Defense Cloud Native & Infrastructure

Added to GitGenius on October 15th, 2026

Created on April 27th, 2026

Open Issues & Pull Requests: 34 (+0)

GitHub issues: Enabled

Number of forks: 7

Total Stargazers: 3 (+0)

Total Subscribers: 2 (+0)

Repository Insights (GitGenius)

Median issue/PR response: 2.0 days

Mean response time: 5.2 days

90th percentile: 15.9 days

Tracked items: 163

Most active contributors

Related repositories by overlapping contributors

Maintainer activity

5 people did triage or write work on this repository in the last 12 months.

Counts unlabeled, assigned, unassigned, milestoned, demilestoned, locked, unlocked over the last 12 months. These are issue and pull request events that require triage or write permission. Commits and code review are not counted. labeled and renamed are excluded because GitHub issue forms record the issue author as the actor. Figures from October 18, 2026. This count is not comparable across projects: each project's automation decides which of these events a person emits. How this is counted.

How this project is maintained

About 11% of issues opened in the past year have never received a reply. Only 6% of open issues come from outside the core team — the tracker reads mainly as internal planning. Work labelled "helm chart" is answered fastest, typically in about 27 hours, while "P3" waits about 6 days. 83% of issues opened in the past year have been closed, leaving a working backlog. Three people close 91% of everything that gets resolved.

Issue Activity (beta)

Open issues: 32

New in 7 days: 4

Closed in 7 days: 5

Avg open age: 50 days

Stale 30+ days: 8

Stale 90+ days: 0

Recent activity

Opened in 7 days: 4

Closed in 7 days: 5

Comments in 7 days: 4

Events in 7 days: 22

Top labels

controller (73)
enhancement (67)
P2 (51)
istio (38)
P3 (24)
documentation (21)
helm chart (18)
P1 (17)

Most active issues this week

Explore full issue details

Detailed Description

Kubewarden Network Enforcer is a Kubernetes security tool that generates and enforces NetworkPolicies from observed workload traffic.

The tool addresses the challenge of moving from permissive networking to policy-driven cluster security by observing real network flows from running workloads, correlating traffic patterns, and producing WorkloadNetworkPolicyProposal resources that describe suggested ingress and egress rules. Teams review and approve these proposals before enforcement, maintaining control while reducing trial-and-error configuration. The system operates through three phases: Learn observes network flows and generates proposals per workload; Monitor reports flows that violate an approved policy without blocking them; Protect enforces the approved policy and blocks violating flows. A Kubernetes controller manages the proposal and policy lifecycle, reading flow telemetry from the configured data-plane provider.

Adoption requires a cluster running Kubernetes 1.31 or later with one of three supported data-plane providers: Istio ambient, Calico with Goldmane, or Cilium with Hubble Relay. The tool also requires cert-manager and the cert-manager-csi-driver. Network Enforcer is deployed via Helm chart and includes a standalone OpenTelemetry collector for handling violation metrics and events, eliminating the need for an external collector in basic setups. This approach suits teams seeking to transition from open networking to enforced policies without manual rule authoring, particularly in environments already running one of the supported CNI solutions.

The project is explicitly marked as experimental and under active development, not yet production-ready. Development activity includes design documentation maintained in RFC form within the repository, and comprehensive user documentation covering quick start, compatibility requirements, and detailed phase explanations. The tool's architecture centers on a controller-based design that integrates with multiple data-plane providers through a pluggable provider interface.