Skip to content

NetworkPolicy Does Not Block Traffic When Expected

Symptom

Traffic continues to flow even though the team expected a NetworkPolicy or Cilium policy to deny it.

Possible Causes

  • The cluster is using a different policy engine than the author assumed.
  • The policy does not select the intended pods.
  • No namespace default-deny baseline exists, so traffic still falls through to default allow.
  • The test path is not the path the policy actually governs.
  • A migration is incomplete and old assumptions about enforcement timing still apply.

Diagnosis Steps

flowchart TD
    A[Traffic still allowed] --> B[Confirm cluster network policy engine]
    B --> C[Inspect policy selectors and targeted pods]
    C --> D{Is there a default-deny baseline?}
    D -->|No| E[Traffic falls through to default allow]
    D -->|Yes| F[Check engine-specific behavior and migration state]
    E --> G[Add or fix baseline then retest]
    F --> G

  1. Confirm the cluster dataplane and network-policy engine.

    az aks show \
    --resource-group "$RG" \
    --name "$CLUSTER_NAME" \
    --query "networkProfile.{dataplane:networkDataplane,policy:networkPolicy,plugin:networkPlugin,mode:networkPluginMode}" \
    --output yaml
    Command Purpose
    az aks show Show the dataplane, policy, plugin, and mode.
    --resource-group Resource group that contains the AKS cluster.
    --name Name of the AKS cluster.
    --query Selects dataplane, policy, plugin, and mode.
    --output Output format for the result.

  2. Inspect the policy and verify that the selected pods are the ones you intended.

    kubectl get networkpolicy \
    --namespace "$NAMESPACE" \
    --output yaml

  3. Check whether a namespace default-deny exists. If not, Kubernetes default behavior remains allow unless a matching policy says otherwise.

  4. If the cluster recently moved to Cilium, confirm the migration finished and all nodes were reimaged before declaring the policy nonfunctional.

Resolution

  • Correct the engine assumption first.
  • Add namespace default-deny baselines where the security model depends on deny-by-default.
  • Fix selectors so the policy actually targets the pods under test.
  • For migrations, wait until the Cilium rollout is complete before validating final enforcement.

Prevention

  • Record the cluster’s current dataplane and policy engine in every troubleshooting ticket.
  • Standardize policy tests so they verify both “should allow” and “should deny” paths.
  • Treat policy migration validation as a staged rollout, not a single command outcome.

See Also

Sources