In projects based on Kubernetes in the Azure cloud, one of the most common mistakes we observe during audits and deployments is the lack of network traffic control between pods.

By default, Kubernetes allows all components to communicate with each other, which in practice means a lack of logical separation and, consequently, a potential compliance problem with regulations (GDPR, NIS2, DORA, ISO 27001).

From our experience, Network Policies in Azure Kubernetes Service (AKS) are not just a technical mechanism, but also a real layer of security & governance control.

In a well-designed environment, network policies become part of the Zero Trust model and are direct proof of security principle enforcement in an audit.

Why Network Policies Matter

Anyone who has ever diagnosed internal traffic in a production cluster knows that without proper rules, it’s easy to have a situation where a frontend component can communicate with a database or an administrative service, even though it shouldn’t.

In real-world deployments, I notice that:

• namespace isolation is often overlooked,
• egress (outbound) traffic is not controlled in any way,
• and the security rules themselves end at the Azure NSG level.

Meanwhile, Network Policies are a mechanism that allows you to:

• enforce communication rules between microservices,
• reduce the attack surface,
• introduce a layer of auditability in the compliance process for ISO, NIST CSF, DORA, NIS2.

Practical Principles for Designing Network Policies

Default Isolation – Default Deny

Every namespace should be isolated from others by default. The absence of this policy is a direct path to lateral movement in the event of a single application compromise.

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

This is the simplest possible manifest, yet it is one of the most frequently overlooked configurations. In practice, we always implement it as a starting point in every cluster, regardless of its size.

Controlled Communication – Whitelisting

After establishing isolation, communication must be opened only where it is necessary. Here is an example of implementing the “least privilege” principle in practice:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-web-to-api
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: api
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: web
    ports:
    - protocol: TCP
      port: 8443
  policyTypes:
  - Ingress

The policy above precisely defines that only the `web` application can communicate with the `api` over port 8443. In accordance with CIS 5.2, this approach ensures the network integrity of the application and minimizes the risk of accidental data exposure.

Egress Traffic Control

Many administrators overlook this direction, but in reality, a lack of egress control is a common data exfiltration vector.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-egress
  namespace: production
spec:
  podSelector:
    matchLabels:
      role: backend
  policyTypes:
  - Egress
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          zone: dmz
    ports:
    - protocol: TCP
      port: 443

This type of policy restricts outgoing traffic to selected segments only. In the context of DORA and NIS2, it can be treated as technical proof of data flow control and risk mitigation for data leakage.

Network Policies in the Context of Compliance

From an audit perspective, every network rule is not just a YAML configuration, but a control artifact – recorded, versioned, and reproducible.

In practice, network policies become part of the risk management system, not just a technical configuration.

GitOps and Infrastructure as Code

The best approach to managing policies is full automation and auditability within the GitOps model. Every policy should adhere to the following principles:

• Versioned in a Git repository,
• Deployed by tools like Jenkins, ArgoCD, Github,
• Monitored in Azure Policy.

Conclusions from Implementations

From deployments in large environments (from the financial to the public sector), we see several key conclusions:

• Network Policies are governance, not configuration. When well-designed, they become part of the compliance structure, not just a technical safeguard.
• Network segmentation genuinely reduces the risk of lateral movement – in penetration tests, namespace isolation effectively stops attacks.
• Kubernetes doesn’t need more security features; it needs more accountability – the most common problems arise from a lack of principles, not a lack of tools or functionality.

Summary

Network Policies in Azure AKS are one of the most underrated security elements. For an auditor, they are proof of compliance; for a DevOps team, a protective layer; and for an architect, a tool for enforcing Zero Trust principles.

If you want your AKS cluster to be truly secure and compliant with regulations, start with a simple step:

Enable default deny and build your communication policies.

Author

Łukasz Tabaczek
Cloud & Security Architect at Professnet

For over two decades, I have been supporting organizations in designing secure and scalable cloud and on-premises environments. I specialize in Cloud, Kubernetes, and DevSecOps technologies, combining technical architecture with a practical approach to compliance and security.