Sunday, June 7, 2026

minkube with kindnet does not support Network Policies. What I loose due to it and what is the solution? (Minikube, Kindnet, and NetworkPolicy Limitations)

By default, Minikube uses Kindnet as its networking plugin. Unfortunately, Kindnet does not support Kubernetes NetworkPolicies. As a result, any NetworkPolicy YAML files you apply are accepted by the Kubernetes API server, but no actual network filtering or firewall rules are enforced.

This means your cluster behaves as if no NetworkPolicies exist at all.

What Cannot Be Tested with Kindnet?

Because Kindnet ignores NetworkPolicies, several important security and networking scenarios cannot be validated.


1. Pod Isolation (Default Deny)

What You Can't Test:

  • Zero Trust networking models.
  • Default-deny ingress policies.
  • Default-deny egress policies.
  • Explicit allow-list based communication.

Behavior in Kindnet:

Every pod can freely communicate with every other pod in every namespace, regardless of any NetworkPolicy objects you create.


2. Namespace Isolation

What You Can't Test:

  • Blocking communication between namespaces.
  • Separating Development, QA, and Production environments.
  • Multi-tenant namespace security boundaries.

Behavior in Kindnet:

Cross-namespace communication remains completely unrestricted.


3. Microservice Segmentation (Application Firewalls)

What You Can't Test:

Policies such as:

Only Pods with the label:

role=frontend

may connect to:

database pods on port 5432

Behavior in Kindnet:

Any pod in the cluster can attempt to connect directly to your database service, making it impossible to validate application-layer network segmentation.


4. Ingress and Egress Traffic Control

What You Can't Test:

Ingress Restrictions

  • Allowing traffic only from a specific API Gateway.
  • Restricting access to approved frontend services.
  • Blocking requests from unauthorized workloads.

Egress Restrictions

  • Blocking outbound internet access.
  • Allowing communication only to approved services.
  • Restricting external API calls.
  • Enforcing outbound compliance policies.

Behavior in Kindnet:

Pods can freely communicate with:

  • Any internal cluster service.
  • Any namespace.
  • Any external IP address.
  • Any public internet endpoint.

5. CIDR-Based IP Allow Lists and Block Lists

What You Can't Test:

  • Allow traffic only from a trusted corporate subnet.
  • Block traffic from untrusted IP ranges.
  • Restrict communication using CIDR rules.
  • External network whitelisting and blacklisting.

Behavior in Kindnet:

CIDR-based filtering policies are ignored entirely.

Quick Comparison

Capability Kindnet Calico
NetworkPolicy Enforcement ❌ No ✅ Yes
Pod Isolation ❌ No ✅ Yes
Namespace Isolation ❌ No ✅ Yes
Ingress/Egress Policies ❌ No ✅ Yes
CIDR Filtering ❌ No ✅ Yes

Switching Minikube to Calico

If you need to test NetworkPolicies properly, destroy the current Kindnet-based cluster and recreate it using Calico.

minikube delete --all

minikube start \
  --driver=docker \
  --network-plugin=cni \
  --cni=calico \
  --nodes=2
Recommendation:
If your goal is to locally test Kubernetes security, NetworkPolicies, Zero Trust networking, namespace isolation, service segmentation, or Istio authorization policies, always use a CNI plugin such as Calico or Cilium rather than Kindnet.

No comments:

Post a Comment

Nodejs : Useful miniscripts

Since Node.js is a scripting language, we can use the "-e" switch to evaluate the text which immediately follows. This allows ...