This is unreleased documentation for Network Enforcer 0.4-dev.

Kubewarden Network Enforcer

Kubewarden Network Enforcer is a Kubernetes operator that observes east-west traffic between workloads, derives an allow-list from what it sees, and, when you opt in, projects that allow-list into a native policy object on a pluggable backend (Istio ambient, Calico, or Cilium).

Kubewarden Network Enforcer is a vendor neutral, CNCF Sandbox project, originally created by SUSE Rancher.

It operates in three phases:

How does Kubewarden Network Enforcer help?

Network Enforcer gives you network policies that match the traffic your workloads produce, and it lets you check each policy before it blocks anything.

Benefits and value

  • Policies come from observed traffic. You do not write rules by hand.

  • Nothing is enforced until you promote a proposal. Promotion is a label on a resource, so it fits a review process and a GitOps workflow.

  • Monitor mode reports what a policy blocks before it blocks. You move to protect mode when the policy is quiet.

  • One model covers Istio ambient, Calico, and Cilium. You select the provider once, at installation.

  • The policy on the data plane is a native object, an AuthorizationPolicy or a NetworkPolicy. You read it with the tools that you already use.

  • Each violation is a record in the policy status and an event with a fixed schema. One query covers all your clusters.

  • Network Enforcer installs one controller. It does not add a node agent or an eBPF probe.

  • Network Enforcer is part of a CNCF project, with an open community.

Use cases

  • Bootstrap. Get a first set of network policies for a cluster that has none.

  • Review. Let each team see what its workload talks to, and approve the policy itself.

  • Detection. Know when a workload talks to a peer that it did not talk to before.

There is further documentation of use cases on the use cases page.

New to Network Enforcer?

Start with the quick start. It installs Network Enforcer on the provider of your choice and walks through the learn, monitor, and protect workflow with two sample workloads. Then read Phases for the full rules of each phase, and Architecture for the components and the flow of data. Operators find the provider requirements in Compatibility and the troubleshooting steps in the how-tos. Security engineers find the violation fields in the glossary. Before you deploy to production, verify the release that you install.

What is learn, monitor, protect?

The three phases are the lifecycle of one policy. In the learn phase, the controller watches traffic and writes a proposal for each workload and direction. In the monitor phase, you have promoted the proposal to a policy. The controller compares new traffic with the policy and reports each mismatch. Nothing is blocked. In the protect phase, the data plane enforces the policy and blocks each mismatch. You move a policy from monitor to protect, and back, with one field. You return to the learn phase when you delete the policy.

Why learn from the data plane?

The information about which workloads talk to each other exists in one place: the flow records of the data plane. A namespace owner knows what the application does, but not which other workloads connect to it. A platform team knows the cluster, but not each application. Network Enforcer reads the flow records and writes them down as a proposal. The people who know the application then review a list instead of a blank page.

Because Network Enforcer reads flows from the data plane that already runs in the cluster, it needs no agent of its own on each node. For the same reason, it writes policy in the format of that data plane. The policy that protects a workload is a standard object that the mesh or the CNI understands, not a format that only Network Enforcer can read.

Vendor neutrality

Network Enforcer is a vendor neutral project as defined by the CNCF.