Introduction

Kubernetes NetworkPolicy objects only work when the cluster's network plugin actually enforces them. That is the crucial detail in Docker Desktop on macOS: there is no simple "enable network policies" checkbox unless the underlying local Kubernetes setup includes a CNI implementation that supports policy enforcement.

NetworkPolicy Is a CNI Feature, Not Just a YAML Feature

You can always apply a manifest such as:

1apiVersion: networking.k8s.io/v1
2kind: NetworkPolicy
3metadata:
4  name: deny-all
5spec:
6  podSelector: {}
7  policyTypes:
8    - Ingress
9    - Egress

and Kubernetes will accept it as an API object.

But that does not mean traffic is actually blocked. Enforcement depends on the container network interface plugin, not on the existence of the NetworkPolicy object by itself.

That is why many people think they "enabled" policy when in reality they only created a resource the local cluster ignores.

The Practical Answer on Docker for Mac

For Docker Desktop's built-in Kubernetes, the practical answer has usually been:

• there is no special Docker Desktop toggle that turns NetworkPolicy enforcement on
• policy support depends on the networking stack provided underneath
• for real local NetworkPolicy testing, use a local cluster setup with a known policy-capable CNI

In other words, if your goal is to verify ingress and egress blocking behavior, Docker Desktop's built-in cluster is often the wrong tool unless you have explicitly added a supported networking layer.

What to Use Instead for Local Testing

If you truly need NetworkPolicy behavior on a laptop, choose an environment where policy-capable CNI support is part of the plan. Common options are:

• 'kind plus a policy-capable CNI'
• 'minikube with a CNI that supports NetworkPolicy'
• another local cluster distribution with explicit policy support

The important point is not the brand of local cluster. The important point is knowing which CNI enforces policy and testing in that environment deliberately.

How to Verify Whether Policies Are Actually Working

Do not trust the fact that kubectl apply succeeded. Test connectivity.

Example test pods:

kubectl run a --image=busybox:1.36 --restart=Never -- sleep 3600
kubectl run b --image=busybox:1.36 --restart=Never -- sleep 3600
kubectl wait --for=condition=Ready pod/a pod/b --timeout=60s

Then try traffic before and after the policy:

kubectl exec a -- wget -qO- http://b:80

If traffic still succeeds after a deny policy that should block it, the usual problem is not your YAML. It is that policy enforcement is not active in the cluster.

Namespace and Label Matching Still Matter

Even with a proper CNI, policies only affect Pods selected by the policy. So once you move to a policy-capable local cluster, make sure your test is still correct:

• are the Pods in the intended namespace
• do labels match the podSelector
• did you define ingress, egress, or both

These questions matter because policy debugging has two layers:

1. is the cluster enforcing policy at all
2. is the specific policy written correctly

Docker Desktop confusion often happens because people jump to the second question before answering the first.

A Minimal Policy Example

Here is a simple ingress-only rule that allows traffic only from Pods labeled app: frontend:

1apiVersion: networking.k8s.io/v1
2kind: NetworkPolicy
3metadata:
4  name: allow-frontend
5spec:
6  podSelector:
7    matchLabels:
8      app: backend
9  policyTypes:
10    - Ingress
11  ingress:
12    - from:
13        - podSelector:
14            matchLabels:
15              app: frontend

This example is useful only in a cluster that actually enforces policies.

The Real Recommendation

If your goal is application development and not security testing, Docker Desktop's built-in Kubernetes can still be fine. But if your goal is validating network isolation semantics, use an environment that explicitly supports them and make that part of your local platform choice.

That saves a lot of time compared with trying to "turn on" a feature that is really owned by the CNI layer.

Common Pitfalls

• Assuming a NetworkPolicy manifest is enforced just because Kubernetes accepted it.
• Looking for a Docker Desktop setting when the feature depends on the network plugin.
• Testing policy behavior in a local cluster that was never designed for it.
• Forgetting to verify with real connectivity tests between Pods.
• Debugging label selectors before proving the cluster enforces policy at all.

Summary

• Kubernetes NetworkPolicy enforcement depends on the cluster's CNI, not just on the YAML resource.
• Docker Desktop on macOS does not provide a simple universal switch for policy enforcement.
• If you need real local NetworkPolicy testing, use a cluster setup with a known policy-capable CNI.
• Always verify policy behavior with live Pod-to-Pod traffic tests.
• Separate "is policy supported" from "is my policy written correctly."