We are thrilled to announce that Layer 7 (L7) Network Policies for Azure Kubernetes Service (AKS), powered by Cilium and Advanced Container Networking Services (ACNS), has reached General Availability (GA)!
The journey from public preview to GA signifies a critical step: L7 Network Policies are now fully supported, highly optimized, and ready for your most demanding, mission-critical production workloads.
A Practical Example: Securing a Multi-Tier Retail Application
Let's walk through a common production scenario. Imagine a standard retail application running on AKS with three core microservices:
- frontend-app: Handles user traffic and displays product information.
- inventory-api: A backend service that provides product stock levels. It should be read-only for the frontend.
- payment-gateway: A highly sensitive service that processes transactions. It should only accept POST requests from the frontend to a specific endpoint.
The Security Challenge: A traditional L4 policy would allow the frontend-app to talk to the inventory-api on its port, but it couldn't prevent a compromised frontend pod from trying to exploit a potential vulnerability by sending a DELETE or POST request to modify inventory data.
The L7 Policy Solution: With GA L7 policies, you can enforce the Principle of Least Privilege at the application layer. Here's how you would protect the inventory-api:
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
name: protect-inventory-api
spec:
endpointSelector:
matchLabels:
app: inventory-api
ingress:
- fromEndpoints:
- matchLabels:
app: frontend-app
toPorts:
- ports:
- port: "8080" # The application port
protocol: TCP
rules:
http:
- method: "GET" # ONLY allow the GET method
path: "/api/inventory/.*" # For paths under /api/inventory/
The Outcome:
- Allowed: A legitimate request from the frontend-app (GET /api/inventory/item123) is seamlessly forwarded.
- Blocked: Assuming frontend-app is compromised, any malicious request (like DELETE /api/inventory/item123) originating from it is blocked at the network layer. This Zero Trust approach protects the inventory-api service from the threat, regardless of the security state of the source service.
This same principle can be applied to protect the payment-gateway, ensuring it only accepts POST requests to the /process-payment endpoint, and nothing else.
Beyond L7: Supporting Zero Trust with Enhanced Security
In addition, toL7 application-level policies to ensure Zero Trust, we support Layer 3/4 network security and advanced egress controls like Fully Qualified Domain Name (FQDN) filtering.
This comprehensive approach allows administrators to:
- Restrict Outbound Connections (L3/L4 & FQDN): Implement strict egress control by ensuring that workloads can only communicate with approved external services. FQDN filtering is crucial here, allowing pods to connect exclusively to trusted external domains (e.g., www.trusted-partner.com), significantly reducing the risk of data exfiltration and maintaining compliance. To learn more, visit the FQDN Filtering Overview.
- Enforce Uniform Policy Across the Cluster (CCNP): Extend protections beyond individual namespaces. By defining security measures as a Cilium Clusterwide Network Policy (CCNP), thanks to its General Availability (GA), administrators can ensure uniform policy enforcement across multiple namespaces or the entire Kubernetes cluster, simplifying management and strengthening the overall security posture of all workloads. To learn
CCNP Example: L4 Egress Policy with FQDN Filtering
This policy ensures that all pods across the cluster (CiliumClusterwideNetworkPolicy) are only allowed to establish outbound connections to the domain *.example.com on the standard web ports (80 and 443).
apiVersion: cilium.io/v2
kind: CiliumClusterwideNetworkPolicy
metadata:
name: allow-egress-to-example-com
spec:
endpointSelector: {} # Applies to all pods in the cluster
egress:
- toFQDNs:
- matchPattern: "*.example.com" # Allows access to any subdomain of example.com
toPorts:
- ports:
- port: "443"
protocol: TCP
- port: "80"
protocol: TCP
Operational Excellence: Observability You Can Trust
A secure system must be observable. With GA, the integrated visibility of your L7 traffic is production ready.
In our example above, the blocked DELETE request isn't silent. It is immediately visible in your Azure Managed Grafana dashboards as a "Dropped" flow, attributed directly to the protect-inventory-api policy. This makes security incidents auditable and easy to diagnose, enabling operations teams to detect misconfigurations or threats in real time. Below is a sample dashboard layout screenshot.
Next Steps: Upgrade and Secure Your Production!
We encourage you to enable L7 Network Policies on your AKS clusters and level up your network security controls for containerized workloads. We value your feedback as we continue to develop and improve this feature. Please refer to the Layer 7 Policy Overview for more information and visit How to Apply L7 Policy for an example scenario.