This is unreleased documentation for Network Enforcer 0.4-dev.

Emergency disable

During an incident, a Network Enforcer policy can block traffic that your team needs. This page stops the blocking with two commands, and restores it with one command once the incident is over.

The commands on this page assume the release name network-enforcer in namespace network-enforcer. Substitute the names from helm list -A if you installed elsewhere.

What enforcement depends on

The data plane enforces a rendered policy: an Istio AuthorizationPolicy, or a Kubernetes NetworkPolicy on Calico and Cilium. The controller renders one rendered policy for every WorkloadNetworkPolicy, and it recreates a rendered policy the moment it disappears.

If the controller stops, every rendered policy stays. See How Kubewarden Network Enforcer scales for why the controller can stop without a gap in enforcement. Stopping the controller does not stop the blocking by itself. You must also remove the rendered policies, which the next section covers.

Stop blocking

1. Scale the controller to zero

Scale the controller Deployment to zero replicas, then wait for its pod to terminate:

kubectl scale deployment network-enforcer-controller-manager \
  -n network-enforcer \
  --replicas=0

kubectl wait --for=delete pod \
  -l app.kubernetes.io/component=controller \
  -n network-enforcer \
  --timeout=60s

Do not go to the next step until the wait command returns. A running controller watches every rendered policy and recreates one the instant you delete it.

While the controller is at zero, learning, promotion, status sync, and violation events all stop. Nothing else breaks: Network Enforcer installs no admission webhook, so every other API write still works. On Istio, the fluent-bit DaemonSet keeps running. It only drops the log records that it cannot forward.

2. Delete the rendered policies

The controller labels every rendered policy with app.kubernetes.io/managed-by=network-enforcer. One label selector finds all of them, and nothing else in the cluster.

Run the command for your provider.

On Istio

kubectl delete authorizationpolicy -A \
  -l app.kubernetes.io/managed-by=network-enforcer

On Calico or Cilium

kubectl delete networkpolicy -A \
  -l app.kubernetes.io/managed-by=network-enforcer

Run only the command for the provider that your cluster uses.

3. Make sure traffic flows

List the rendered policies again, with the same selector you deleted with:

kubectl get networkpolicy,authorizationpolicy -A \
  -l app.kubernetes.io/managed-by=network-enforcer

The list is empty. Traffic that a rendered policy blocked now flows, within seconds of the deletion. Run the request that the incident needed, and make sure that it succeeds.

Restore protection

Scale the controller back up:

kubectl scale deployment network-enforcer-controller-manager \
  -n network-enforcer \
  --replicas=1

Use the replica count that you ran before the incident, if you changed controller.replicas from its default.

On startup, the controller reconciles every WorkloadNetworkPolicy and renders each protect policy again. You do not patch anything, and you do not relabel anything. Run the list command from step 3 again, and the rendered policies reappear.

Do not

Do not delete a rendered policy while the controller runs

The controller watches every rendered policy that it owns. If you delete one while the controller runs, the controller recreates it at once.

Do not patch `spec.mode` while the controller is down

The Kubernetes API accepts a patch to spec.mode even with the controller at zero, because Network Enforcer installs no admission webhook. Only the controller turns that patch into a change on the rendered policy. With the controller down, the patch changes nothing, and the policy keeps blocking.