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:
Provider | Features | When to Use |
---|---|---|
Azure Network Policy Manager | Native, simple, integrates with Azure NSG | Basic isolation, Azure-centric |
Calico | Advanced, supports egress, DNS, global policies | Complex policies, multi-cluster |
Cilium | eBPF-based, deep observability, L7 policies | High performance, zero-trust, L7 |
Feature Comparison
Capability | Azure Network Policy Manager | Calico | Cilium |
---|---|---|---|
Supported platforms | Linux, Windows Server 2022 (Preview) | Linux, Windows Server 2019 and 2022 | Linux |
Supported networking options | Azure Container Networking Interface (CNI) | Azure CNI (Linux, Windows Server 2019/2022), kubenet (Linux) | Azure CNI |
Compliance with Kubernetes spec | All policy types are supported | All policy types are supported | All policy types are supported |
Other features | None | Many features not tested/supported by AKS | FQDN and L7 |
Support | Azure Support and Engineering team | Azure Support and Engineering team | Azure 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.