Kubewarden Network Enforcer use cases

My cluster has workloads but no network policies. I know that I must add policies. I do not know which workloads talk to each other. That information is in the flow records of the data plane, not in a Kubernetes API object.

I install Network Enforcer once, for the whole cluster. I point it at the flow source of my data plane. Learning starts at once and needs no configuration per workload.

For each Deployment, StatefulSet, and DaemonSet that carries traffic, Network Enforcer creates a WorkloadNetworkPolicyProposal. One proposal covers one workload and one direction. The proposal contains the peers, protocols, and ports that Network Enforcer observed. This list is the allow-list. Learning continues until I promote the proposal.

Learning starts when the controller starts. Traffic from before that moment is not in the proposals. If a workload is quiet, I exercise it or restart it so that its flows are observed.

See Learn phase and Learning starts when the controller starts.

I know what my application does. I do not always know which other workloads connect to it. The proposal for my workload lives in my namespace. It is owned by my Deployment, StatefulSet, or DaemonSet. I read it with my normal Kubernetes permissions:

I review the peers and ports in the proposal. If the list is correct, I set the label networkenforcer.kubewarden.io/promote to monitor on the proposal. Network Enforcer creates a WorkloadNetworkPolicy and removes the proposal. Nothing is enforced yet.

If I delete the WorkloadNetworkPolicy, Network Enforcer learns a new proposal for the workload. If I delete the workload, Kubernetes removes its proposals with it.

See Transitions.

I do not want to break production with a wrong rule. I promote the proposal to monitor mode first. In this mode, Network Enforcer compares new flows with the policy. It records each flow that the policy does not allow as a violation. The data plane does not drop the flow.

I watch the Active Violations column of the WorkloadNetworkPolicy. I examine each violation. If the traffic is expected, I add a rule to the policy, so that the next flow is allowed. I then acknowledge the existing violation. If the traffic is noise that I understand, I acknowledge the violation with the annotation networkenforcer.kubewarden.io/acknowledge-<id> and a reason.

When the policy has no active violations for a period that I trust, I set spec.mode to protect. Network Enforcer creates the native policy object on the data plane. If a problem occurs, I set spec.mode back to monitor. Network Enforcer removes the native policy object.

On Calico and Cilium, monitor mode does not create an object in the data plane. The controller only sees the flows that the scraper receives. A flow that the scraper does not see is not reported.

See Monitor phase, Protect phase, and Acknowledge a violation.

An approved policy describes the expected traffic of a workload. A violation of that policy is a signal. In monitor mode the signal does not block. In protect mode the signal shows a blocked connection. In both modes I want a record.

Network Enforcer writes the violations to the status of the WorkloadNetworkPolicy. The status keeps the 100 most recent violation records. For a longer history, I use OpenTelemetry. Network Enforcer emits a policy_violation_observed log event for each violation. Each event has a fixed set of attributes: the source workload, the destination workload, the protocol, the port, the mode, and the policy.

I send the events to the OpenTelemetry collector that Network Enforcer installs, or to my own collector. From there they go to my dashboards or my SIEM. The attribute names do not change between providers. One query covers Istio, Calico, and Cilium clusters.

See OpenTelemetry collector, Where OTLP events go, and Violation status is capped at 100 records.

I do not want to change my CNI or install a new mesh to get network policies. Network Enforcer reads flows from the data plane that is already there. It writes policies in the native format of that data plane. I select the provider once, at installation time.

Istio ambient. Network Enforcer reads the access logs of ztunnel. It learns the ingress traffic of each workload. The policy identifies each peer by its SPIFFE principal, which comes from the ServiceAccount of the workload. In protect mode, Network Enforcer creates an Istio AuthorizationPolicy. Workloads that share the default ServiceAccount also share one identity. The policy for them is wider than I want. A policy in the Kubewarden Admission Controller can require a dedicated ServiceAccount for each workload.

Calico and Cilium. Network Enforcer reads flows from Goldmane or Hubble Relay. It learns both ingress and egress traffic, for TCP and UDP. In protect mode, it creates a standard Kubernetes NetworkPolicy. The CNI enforces it. I can read the policy with the tools that I already use.

The backend field, spec.backend, of a policy cannot change. If I move a cluster to a different provider, Network Enforcer learns new proposals.

See Provider matrix, Capability matrix, Backend selection, and Istio learns and enforces ingress only.

Network Enforcer does not intend to: