Network Policies

Network policies are essential for securing traffic between pods in your Kubernetes cluster. They allow you to define rules that control which pods can communicate with each other and with external resources. They allow you to:

  • Restrict pod-to-pod communication to only what’s necessary.
  • Enforce segmentation for sensitive workloads.
  • Make network flows explicit and auditable.

Supported Network Policy Providers in AKS

AKS supports several network policy engines, each with different capabilities:

ProviderFeaturesWhen to Use
Azure Network Policy ManagerNative, simple, integrates with Azure NSGBasic isolation, Azure-centric
CalicoAdvanced, supports egress, DNS, global policiesComplex policies, multi-cluster
CiliumeBPF-based, deep observability, L7 policiesHigh performance, zero-trust, L7

Feature Comparison

CapabilityAzure Network Policy ManagerCalicoCilium
Supported platformsLinux, Windows Server 2022 (Preview)Linux, Windows Server 2019 and 2022Linux
Supported networking optionsAzure Container Networking Interface (CNI)Azure CNI (Linux, Windows Server 2019/2022), kubenet (Linux)Azure CNI
Compliance with Kubernetes specAll policy types are supportedAll policy types are supportedAll policy types are supported
Other featuresNoneMany features not tested/supported by AKSFQDN and L7
SupportAzure Support and Engineering teamAzure Support and Engineering teamAzure Support and Engineering team

When choosing a network policy provider, consider the following:

  • Choose Azure Network Policy Manager for simplicity and Azure integration.
  • Use Calico or Cilium for advanced features (e.g., DNS-based rules, egress control, L7 policies).
  • Calico and Cilium may introduce additional overhead but offer more granular control.
  • Not all features are available with every CNI/networking mode. Check compatibility with your chosen CNI.

Implementing Network Policies

A NetworkPolicy in Kubernetes is an object that defines how groups of pods are allowed to communicate with each other and with other network endpoints. It acts as a firewall at the pod level, specifying what traffic is allowed to and from selected pods.

  • The podSelector field determines which pods the policy applies to. Only pods matching the selector are affected by the policy.
  • Ingress rules control incoming traffic to the selected pods.
  • Egress rules control outgoing traffic from the selected pods.
  • to / from Selectors allow you to specify which other pods, namespaces, or IP blocks are allowed to communicate with the selected pods.

In the example below, we create a network policy that allows traffic only from pods with the label app: myapp to other pods with the same label. This is useful for isolating application components within the same application while preventing access from other applications or external sources.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-same-app
spec:
  podSelector:
    matchLabels:
      app: myapp
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: myapp

Default Behaviour

By default, if no network policies are applied, all pods can communicate with each other. This is known as the “default allow” behavior. Once you apply a network policy to a pod, it becomes isolated. If you wish to implement a “default deny” approach, and require explicit policies to allow traffic, you can create a policy that denies all traffic to pods without any specific ingress or egress rules.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
spec:
  podSelector: {}
  policyTypes:
  - Ingress

This policy applies to all pods in the namespace and denies all incoming traffic unless explicitly allowed by other policies.

Further Reading and Resources