Azure Kubernetes Service
AKS Security
Open Service Mesh
A service mesh in Kubernetes offers a dedicated communication layer that abstracts networking and infrastructure concerns away from application code. By injecting a lightweight proxy—called a sidecar—next to each service instance, it intercepts all inbound and outbound traffic. This approach provides consistent traffic management, mTLS security, and observability without changing your application.
Services (e.g., frontend, middle-tier, backend) run alongside their respective sidecar proxies. Although deployed together, proxies are managed independently, allowing you to update or scale them separately. The result is a clean codebase while the mesh transparently handles retries, circuit breaking, encryption, and more.
Open Service Mesh (OSM) for AKS consists of two main layers: the data plane and the control plane.
Data Plane
The data plane is responsible for the actual routing of network traffic between services. Its key functions include:
- Service discovery: Automatically finding and routing to healthy instances.
- Traffic management: Implementing retries, circuit breakers, and load balancing.
- Security: Establishing mutual TLS (mTLS) channels for encrypted, authenticated communication.
Control Plane
The control plane provides centralized orchestration and visibility. It:
- Provisions and scales service instances.
- Monitors pod health and replaces unhealthy instances.
- Enforces policies such as rate limits, access control, and routing rules.
Popular Service Mesh Implementations
Implementation | Language/Platform | Key Characteristics |
---|---|---|
Istio | Go | Extensible, full-featured, advanced policy engine |
Linkerd | Scala (JVM) | Lightweight, simplicity-first, low overhead |
Open Service Mesh (OSM) | Go | CNCF-compliant, Envoy-based, lightweight control plane |
On Azure Kubernetes Service (AKS), OSM was the original built-in mesh, and Istio is now available in preview. This guide will focus on deploying and using OSM on AKS.
Features of Open Service Mesh
- Simplified control plane for easy operations
- Envoy sidecars for CNCF-approved, high-performance proxying
- Traffic policies: access control, traffic splitting, telemetry
- Fine-grained mTLS for service-to-service encryption
- Integration with Prometheus, Grafana, Jaeger for monitoring and tracing
- Support for external certificate authorities in production
Demo Architecture
We’ll deploy a sample bookstore application on AKS with OSM in permissive mode. The demo includes:
- Book Buyer (client)
- Bookstore V1 (primary backend)
- Bookstore V2 (for traffic splitting)
- Book Warehouse (additional service)
The workflow covers enabling OSM, onboarding namespaces, testing default traffic, toggling permissive mode, applying explicit policies, and performing traffic splits.
Prerequisites
- Azure CLI installed
kubectl
configured locallyosm
CLI for namespace onboarding
1. Create Resource Group and AKS Cluster
# Create a resource group
az group create -l southeastasia -n kodekloud-osmdemo-rg
# Create AKS cluster with the OSM add-on
az aks create \
-g kodekloud-osmdemo-rg \
-n kk-aks-osmdemo \
--enable-addons open-service-mesh
2. Configure kubectl Context
# Fetch AKS credentials
az aks get-credentials -g kodekloud-osmdemo-rg -n kk-aks-osmdemo
# Confirm the current context
kubectl config current-context
3. Create Namespaces and Onboard to OSM
# Create application namespaces
kubectl create ns bookbuyer bookstore bookwarehouse
# Add namespaces to the mesh
osm namespace add bookbuyer bookstore bookwarehouse
4. Deploy Sample Applications
# Deploy the Book Buyer client
kubectl apply -f https://raw.githubusercontent.com/openservicemesh/osm/release-v0.11/docs/example/manifests/apps/bookbuyer.yaml
# Deploy Bookstore V1
kubectl apply -f https://raw.githubusercontent.com/openservicemesh/osm/release-v0.11/docs/example/manifests/apps/bookstore.yaml
# Deploy the Book Warehouse
kubectl apply -f https://raw.githubusercontent.com/openservicemesh/osm/release-v0.11/docs/example/manifests/apps/bookwarehouse.yaml
Wait for the Book Buyer pod:
kubectl get pods -n bookbuyer -w
5. Port-Forward and Verify Default Traffic
# Retrieve the Book Buyer pod name
POD=$(kubectl get pod -n bookbuyer -l app=bookbuyer -o jsonpath='{.items[0].metadata.name}')
# Forward local port 8081 to the sidecar port
kubectl port-forward -n bookbuyer $POD 8081:14001
Open http://localhost:8081
to see Book Buyer successfully fetching from Bookstore V1 under OSM’s permissive policy.
Note
Permissive mode allows all services in the mesh to communicate without explicit SMI traffic policies.
6. Disable Permissive Traffic Policy
In the Azure Portal under AKS → Open Service Mesh → Configuration, update:
traffic:
enableEgress: true
enablePermissiveTrafficPolicyMode: false
After saving, Book Buyer will fail to reach Bookstore V1.
kubectl logs -n bookbuyer $POD
# Look for denied request errors.
Warning
Disabling permissive mode without defining traffic policies will block all inter-service communication.
7. Apply Explicit Allow Traffic Policy
kubectl apply -f https://raw.githubusercontent.com/openservicemesh/osm-docs/release-v1.2/manifests/access/traffic-access-v1.yaml
This SMI policy permits Book Buyer to call Bookstore. Reload http://localhost:8081
to confirm connectivity.
8. Demonstrate Traffic Splitting
Create traffic-split.yaml
:
apiVersion: split.smi-spec.io/v1alpha2
kind: TrafficSplit
metadata:
name: bookstore-split
namespace: bookstore
spec:
service: bookstore
backends:
- service: bookstore-v1
weight: 500m
- service: bookstore-v2
weight: 500m
Apply the split:
kubectl apply -f traffic-split.yaml
Refresh the Book Buyer page—traffic should now be distributed evenly between V1 and V2. Adjust the weight
values to shift more traffic to a particular version.
References
Further Reading
Watch Video
Watch video content