DEV Community: Mikael Krief

Choosing the Right Azure Container Service: Comparison and Decision Guide

Mikael Krief — Thu, 22 Jan 2026 21:56:03 +0000

As a developer building modern applications—whether it's a Node.js API, a Python web application, or a .NET microservice—you're likely considering containerization for its portability, consistency, and scalability benefits. Once you've containerized your application, the next critical decision is: where should you deploy it?

Microsoft Azure offers a rich ecosystem of container hosting services, each designed for specific use cases, workload requirements, and operational complexity levels. The abundance of choices can be overwhelming: Should you use Azure Container Instances for simplicity? Azure Kubernetes Service for orchestration? Azure Container Apps for serverless containers? Or perhaps Azure App Service for a fully managed PaaS experience?

This article serves as your comprehensive guide to understanding and choosing the right Azure container service. We'll explore:

Four major Azure container services: Their architectures, capabilities, and ideal use cases
Detailed comparisons: Advantages, disadvantages, and key differentiators
Decision framework: How to choose the right service for your specific needs
Real-world scenarios: Practical examples to guide your decision
Migration paths: Understanding how you might evolve from one service to another

Whether you're deploying your first containerized application or optimizing an existing container strategy, this guide will help you make an informed decision that balances your technical requirements, operational capabilities, and business objectives.

Understanding Azure Container Services

Azure provides multiple container hosting options, each sitting at different points on the spectrum of control vs. convenience:

1. Azure Container Instances (ACI)

Azure Container Instances is the fastest and simplest way to run a container in Azure without managing any virtual machines or adopting a higher-level service. It's designed for isolated containers that can run without orchestration.

Architecture and Key Features

Serverless containers: No VM management, pay only for what you use
Fast startup: Containers start in seconds
Per-second billing: Cost-effective for short-lived workloads
Flexible sizing: Specify exact CPU cores and memory
Virtual network integration: Deploy containers into Azure VNets
Persistent storage: Mount Azure Files shares
Container groups: Co-locate multiple containers on a single host
Windows and Linux: Support for both container types

Advantages

Simplicity: Easiest way to run containers in Azure—no orchestration needed
Speed: Fastest container startup times (typically 3-5 seconds)
Cost-effective for burst workloads: Per-second billing makes it ideal for short-running tasks
No infrastructure management: Truly serverless container experience
Hybrid connectivity: Can be deployed to on-premises environments via Azure Arc
Sidecar patterns: Container groups enable multi-container deployments

Disadvantages

No built-in orchestration: No automatic scaling, load balancing, or self-healing
Limited high availability: Single instance deployment by default
No rolling updates: Updates require manual intervention
Stateful workloads require planning: Persistent storage setup is more manual
Limited monitoring: Basic monitoring compared to orchestrated services
No service mesh: Advanced networking features not available

Ideal Use Cases

Batch processing and data transformation jobs
CI/CD build agents and task runners
Event-driven workloads triggered by Azure Functions or Logic Apps
Development and testing environments
Simple web applications without complex orchestration needs
Bursting from AKS when additional capacity is needed temporarily

Example Deployment

az container create \
  --resource-group myResourceGroup \
  --name mynodeapp \
  --image myregistry.azurecr.io/nodeapp:latest \
  --cpu 1 \
  --memory 1.5 \
  --dns-name-label mynodeapp-unique \
  --ports 3000 \
  --environment-variables NODE_ENV=production

2. Azure Container Apps

Azure Container Apps is a fully managed serverless container service built on Kubernetes that enables you to run microservices and containerized applications without worrying about orchestration. It's powered by KEDA (Kubernetes Event-Driven Autoscaling), Dapr (Distributed Application Runtime), and Envoy.

Architecture and Key Features

Serverless Kubernetes: Built on AKS but abstracts away cluster management
Event-driven scaling: Scale to zero and scale based on HTTP traffic, messages, or custom metrics
Integrated Dapr: Built-in support for microservices patterns (pub/sub, state management, service-to-service calls)
Revisions management: Built-in versioning and traffic splitting
Multiple revision modes: Single or multiple active revisions
Ingress and traffic splitting: Sophisticated routing capabilities
KEDA integration: Scale based on diverse event sources
Secrets management: Integration with Azure Key Vault

Advantages

Kubernetes benefits without complexity: Get orchestration without managing clusters
Scale to zero: Reduce costs by scaling to zero when not in use
Microservices-ready: Built-in Dapr support for distributed application patterns
Blue-green deployments: Native support for traffic splitting between revisions
Cost-effective: Pay only for the resources your containers use
Event-driven autoscaling: Sophisticated scaling based on 50+ event sources via KEDA
Developer-friendly: Simplified deployment model compared to raw Kubernetes
Integrated observability: Built-in logging and monitoring with Azure Monitor

Disadvantages

Less control than AKS: Abstract layer means less low-level Kubernetes control
Kubernetes knowledge still helpful: Understanding K8s concepts aids troubleshooting
Limited customization: Can't modify underlying Kubernetes cluster
Newer service: Smaller community and fewer third-party integrations than AKS
Regional availability: Not available in all Azure regions
No Windows containers: Linux containers only (as of current version)

Ideal Use Cases

Microservices architectures
API backends and REST services
Event-driven applications (queue processing, event handlers)
Background processing and scheduled jobs
Web applications with variable traffic patterns
Applications that need to scale to zero
Gradual migration from monolith to microservices

Example Deployment

az containerapp create \
  --name my-node-api \
  --resource-group myResourceGroup \
  --environment my-environment \
  --image myregistry.azurecr.io/nodeapp:latest \
  --target-port 3000 \
  --ingress external \
  --min-replicas 0 \
  --max-replicas 10 \
  --cpu 0.5 \
  --memory 1Gi \
  --env-vars NODE_ENV=production

3. Azure Kubernetes Service (AKS)

Azure Kubernetes Service is a managed Kubernetes service that provides the full power and flexibility of Kubernetes while Microsoft manages the control plane. It's the go-to choice for complex, production-grade container orchestration at scale.

Architecture and Key Features

Managed control plane: Microsoft manages and patches the Kubernetes masters
Full Kubernetes API: Complete access to all Kubernetes features
Node pools: Multiple node pools with different VM sizes and configurations
Autoscaling: Cluster autoscaler and horizontal pod autoscaler
Integrated networking: Azure CNI or Kubenet networking options
Azure integration: Native integration with Azure Monitor, Azure AD, ACR, and more
Security features: Azure Policy, Azure RBAC, pod security standards
Windows containers: Support for both Linux and Windows node pools
Confidential computing: Support for confidential containers

Advantages

Enterprise-grade: Production-ready for mission-critical workloads
Full Kubernetes capabilities: Access to entire Kubernetes ecosystem and tooling
Maximum flexibility: Complete control over cluster configuration
Hybrid and multi-cloud: Run workloads across Azure, on-premises, and other clouds with Azure Arc
Rich ecosystem: Vast library of Helm charts, operators, and tools
Advanced networking: Service mesh, network policies, ingress controllers
Mature and proven: Battle-tested by thousands of organizations
Strong Azure integration: ACR, Azure AD, Key Vault, Azure Monitor, Azure Policy
Windows support: Run Windows containers alongside Linux

Disadvantages

Complexity: Steeper learning curve, requires Kubernetes expertise
Operational overhead: More to manage (upgrades, node pools, scaling policies)
Cost: Always-on control plane and worker nodes (minimum cluster costs)
Longer deployment times: Cluster provisioning takes longer than serverless options
Requires DevOps skills: Need expertise in Kubernetes, networking, security
Overhead for simple apps: May be overkill for simple containerized applications

Ideal Use Cases

Large-scale microservices architectures
Complex distributed systems
Multi-tenant applications
Applications requiring specific Kubernetes features or operators
Hybrid and multi-cloud deployments
Organizations with Kubernetes expertise
Mission-critical, enterprise applications
Machine learning pipelines and GPU workloads
Long-running stateful services (databases, caches)

Example Deployment

# Create AKS cluster
az aks create \
  --resource-group myResourceGroup \
  --name myAKSCluster \
  --node-count 3 \
  --node-vm-size Standard_D4s_v3 \
  --enable-managed-identity \
  --enable-addons monitoring \
  --enable-cluster-autoscaler \
  --min-count 1 \
  --max-count 5 \
  --network-plugin azure

# Deploy application
kubectl apply -f deployment.yaml

4. Azure App Service for Containers

Azure App Service for Containers (also known as Web App for Containers) extends the popular Azure App Service platform to support custom Docker containers. It provides a fully managed hosting environment with built-in DevOps capabilities.

Architecture and Key Features

Fully managed PaaS: Complete infrastructure and runtime management
Built-in CI/CD: Integration with GitHub Actions, Azure DevOps, Docker Hub
Auto-scaling: Built-in autoscaling based on metrics
Deployment slots: Staging environments and traffic routing
Custom domains and SSL: Easy setup for production domains
Hybrid connections: Connect to on-premises resources
Always On: Keep your app warm and responsive
Authentication: Built-in authentication with Azure AD, Google, Facebook, etc.
Sidecar containers: Support for multi-container scenarios using sidecars

Advantages

Easiest managed service: Simplest production-ready hosting option
Rich PaaS features: Deployment slots, easy rollback, auto-heal
Excellent DevOps integration: Built-in CI/CD pipelines
Global scale: Deploy to multiple regions easily
Built-in load balancing: Automatic traffic distribution
Familiar to App Service users: Low learning curve if you already use App Service
Cost-effective for web apps: Good pricing for standard web applications
Integrated authentication: Easy setup of identity providers

Disadvantages

Limited to web applications: Best suited for HTTP-based apps
Less flexibility: Can't run complex multi-container architectures
Limited multi-container support: Sidecars available but with constraints compared to orchestrators
App Service limitations: Subject to App Service plan limitations
Less suitable for microservices: Not designed for complex service-to-service communication
Vendor lock-in: More Azure-specific than standard Kubernetes

Ideal Use Cases

Web applications and APIs
Traditional monolithic applications containerized
Teams already familiar with Azure App Service
Applications needing built-in authentication
Gradual migration from VMs or App Service to containers
SaaS applications with multi-tenant architectures
Content management systems (WordPress, Drupal, etc.)

Example Deployment

az webapp create \
  --resource-group myResourceGroup \
  --plan myAppServicePlan \
  --name my-node-webapp \
  --deployment-container-image-name myregistry.azurecr.io/nodeapp:latest \
  --docker-registry-server-user <username> \
  --docker-registry-server-password <password>

# Enable continuous deployment
az webapp deployment container config \
  --name my-node-webapp \
  --resource-group myResourceGroup \
  --enable-cd true

Comparison Matrix

Feature	ACI	Container Apps	AKS	App Service
Orchestration	None	Managed K8s	Self-managed K8s	App Service
Complexity	Very Low	Low	High	Low
Scale to Zero	No	Yes	No	No
Startup Time	Seconds	Seconds	Minutes	Seconds-Minutes
Control Level	Low	Medium	Very High	Low
Multi-container	Limited (groups)	Yes	Yes	Limited
Auto-scaling	No	Yes	Yes (HPA/CA)	Yes
Cost Model	Per-second	Consumption	Always-on	Always-on
Learning Curve	Minimal	Low	Steep	Minimal
Best For	Simple tasks	Microservices	Enterprise	Web apps
Windows Support	Yes	No	Yes	Yes
Hybrid/Arc	Yes	Limited	Yes	Yes
Min Monthly Cost	~$0	~$0	~$70-150	~$55

Decision Framework: Choosing the Right Service

Decision Tree

Start: Do you need container orchestration?
│
├─ No → Do you need to run simple, isolated containers?
│   ├─ Yes → Do you need per-second billing for burst workloads?
│   │   ├─ Yes → **Azure Container Instances**
│   │   └─ No → Is it a web application with DevOps integration?
│   │       ├─ Yes → **Azure App Service for Containers**
│   │       └─ No → **Azure Container Instances**
│   │
├─ Yes → Do you need to scale to zero?
    ├─ Yes → Are you building microservices?
    │   ├─ Yes → **Azure Container Apps**
    │   └─ No → **Azure Container Apps** or **Azure Container Instances**
    │
    └─ No → Do you need full Kubernetes control?
        ├─ Yes → **Azure Kubernetes Service**
        └─ No → **Azure Container Apps**

Decision Criteria by Priority

Choose Azure Container Instances when:

You need the simplest deployment model
Running batch jobs, CI/CD tasks, or event-driven workloads
Cost optimization for short-lived containers is critical
No orchestration or high availability required
Quick prototyping or development/test scenarios

Choose Azure Container Apps when:

Building microservices without Kubernetes complexity
Need event-driven autoscaling and scale-to-zero
Want Dapr integration for distributed application patterns
Require blue-green deployments and traffic splitting
Cost-conscious and want consumption-based pricing
Modern cloud-native applications with varying load

Choose Azure Kubernetes Service when:

Need full Kubernetes capabilities and ecosystem
Building complex, enterprise-grade systems
Require specific Kubernetes features, operators, or tools
Need hybrid/multi-cloud deployments
Have Kubernetes expertise in your team
Running stateful workloads at scale
Need Windows container support alongside Linux

Choose Azure App Service for Containers when:

Migrating traditional web applications to containers
Already using Azure App Service successfully
Need simplest PaaS with containers
Want built-in authentication and easy SSL
Prioritize DevOps integration and deployment slots
Running monolithic web applications

Real-World Scenarios

Scenario 1: E-commerce Application

Requirements:

Public-facing web application with Node.js frontend and Python backend
Variable traffic (spikes during sales, low overnight)
Need to scale automatically
Multiple microservices (catalog, cart, payment, inventory)
Budget-conscious startup

Recommendation: Azure Container Apps

Rationale:

Scale to zero during low-traffic periods saves costs
Microservices architecture fits Container Apps model
Event-driven scaling handles traffic spikes
Built-in Dapr simplifies service-to-service communication
Lower operational overhead than AKS
Can migrate to AKS later if complexity increases

Scenario 2: Data Processing Pipeline

Requirements:

Process files uploaded to Azure Blob Storage
Containerized Python application
Runs for 5-15 minutes per job
Triggered by events (blob creation)
20-30 jobs per day

Recommendation: Azure Container Instances

Rationale:

Per-second billing is cost-effective for short-running jobs
No orchestration needed for isolated tasks
Fast startup time
Can be triggered by Azure Functions or Logic Apps
Simple deployment and management
Pay only for actual processing time

Scenario 3: Enterprise SaaS Platform

Requirements:

Complex multi-tenant application
50+ microservices
Strict security and compliance requirements
Need service mesh for observability
Stateful services (Redis, RabbitMQ, databases)
24/7 availability
Existing Kubernetes expertise

Recommendation: Azure Kubernetes Service

Rationale:

Full Kubernetes capabilities for complex requirements
Can implement service mesh (Istio, Linkerd)
Supports stateful workloads with StatefulSets
Advanced networking and security policies
Existing team expertise reduces learning curve
Complete control over configuration
Rich ecosystem for all requirements

Scenario 4: Corporate Website and Blog

Requirements:

WordPress running in a container
Custom PHP application
Need staging and production environments
SSL certificate management
Azure AD authentication for admin portal
Simple deployment process

Recommendation: Azure App Service for Containers

Rationale:

Deployment slots for staging/production
Built-in SSL and custom domain support
Easy Azure AD authentication integration
Familiar to web developers
Automatic load balancing
Simple CI/CD integration
Managed backups and disaster recovery

Migration Paths and Evolution

Progressive Adoption Strategy

Many organizations follow a progressive path as their container maturity grows:

Start Simple: Azure Container Instances or App Service for Containers
- Learn containerization basics
- Minimal operational overhead
- Quick wins and learning
Add Orchestration: Azure Container Apps
- Introduce microservices patterns
- Scale-to-zero for cost optimization
- Event-driven architectures
Enterprise Scale: Azure Kubernetes Service
- Full Kubernetes control
- Complex architectures
- Existing Kubernetes expertise

Hybrid Deployments

You can also use multiple services simultaneously:

AKS + ACI: Use AKS for long-running services and burst to ACI for temporary workload spikes (via Virtual Kubelet)
Container Apps + ACI: Use Container Apps for APIs and ACI for batch jobs
AKS + App Service: Legacy apps on App Service, new microservices on AKS
Multi-region: Different services in different regions based on requirements

Best Practices and Recommendations

General Container Best Practices

Use Azure Container Registry (ACR):
- Geo-replication for global deployments
- Vulnerability scanning with Microsoft Defender
- Efficient image storage and caching
- Tight integration with all Azure container services
Implement CI/CD:
- Automate builds with GitHub Actions or Azure DevOps
- Use Azure Container Registry Tasks for automated builds
- Implement gitops workflows for Kubernetes
Security:
- Scan images for vulnerabilities before deployment
- Use managed identities instead of service principals
- Implement network policies and private endpoints
- Rotate secrets regularly using Azure Key Vault
Monitoring and Observability:
- Enable Azure Monitor Container Insights
- Implement application-level logging
- Use Application Insights for distributed tracing
- Set up alerts for critical metrics
Cost Optimization:
- Right-size your containers (CPU/memory)
- Use scale-to-zero where appropriate
- Implement autoscaling to handle traffic patterns
- Consider spot instances for non-critical AKS workloads
- Review and optimize regularly

Service-Specific Best Practices

Azure Container Instances

Use container groups for sidecar patterns (logging, monitoring)
Leverage Azure Files for persistent storage
Use virtual network integration for secure deployments
Consider ACI for dev/test to reduce costs

Azure Container Apps

Design for scale-to-zero to maximize cost savings
Use Dapr components for common patterns
Implement health probes for reliability
Use revisions for safe deployments
Leverage built-in authentication for APIs

Azure Kubernetes Service

Use multiple node pools for workload isolation
Enable cluster autoscaler for dynamic scaling
Implement pod security policies/standards
Use Azure Policy for governance
Regular cluster upgrades following N-2 support policy
Consider Azure CNI for advanced networking

App Service for Containers

Use deployment slots for zero-downtime deployments
Enable Application Insights for monitoring
Configure health checks for auto-heal
Use App Service Environment for isolation requirements
Leverage built-in authentication

Cost Considerations

Approximate Monthly Costs (as of January 2026)

Azure Container Instances:

Pay-per-second: ~$0.0000012/vCPU-second + $0.0000001/GB-second
Example: 1 vCPU, 1.5GB running 24/7 ≈ $40-50/month
Ideal for burst workloads and batch jobs

Azure Container Apps:

Consumption plan: $0.000012/vCPU-second + $0.000002/GiB-second
Free tier: 180,000 vCPU-seconds and 360,000 GiB-seconds per month
Example: Small API with scale-to-zero ≈ $0-30/month

Azure Kubernetes Service:

Control plane: Free (managed by Azure)
Worker nodes: VM costs (~$70/month per Standard_B2s node)
Example: 3-node cluster ≈ $210/month + additional resources
Additional costs: Load balancers, public IPs, storage

App Service for Containers:

Basic B1: ~$55/month (1 core, 1.75GB)
Standard S1: ~$75/month (1 core, 1.75GB) + deployment slots
Premium P1v3: ~$130/month (2 cores, 8GB)

Cost Optimization Tips

Use scale-to-zero for variable workloads (Container Apps)
Right-size your containers and VMs
Use Azure Spot VMs for AKS non-critical workloads (60-90% discount)
Implement autoscaling to match demand
Use Azure Reservations for predictable workloads (up to 72% savings)
Enable container insights only where needed
Use shared node pools in AKS for multiple namespaces

Conclusion

Choosing the right Azure container service is a critical decision that impacts your application's scalability, reliability, cost, and operational complexity. There is no one-size-fits-all solution—the best choice depends on your specific requirements, team expertise, and organizational goals.

Quick Recommendations Summary

Just getting started with containers? → Start with Azure Container Instances or Azure App Service for Containers
Building modern microservices? → Choose Azure Container Apps
Need full Kubernetes power? → Go with Azure Kubernetes Service
Traditional web apps? → Use Azure App Service for Containers

Key Takeaways

Start simple and evolve: Begin with simpler services (ACI, App Service) and evolve to more complex orchestration (Container Apps, AKS) as needs grow.
Consider operational maturity: Your team's expertise should influence the decision. Don't choose AKS if you lack Kubernetes skills without a plan to build that capability.
Cost vs. features trade-off: More managed services (Container Apps, App Service) typically offer better cost efficiency for standard workloads, while full control (AKS) provides flexibility at higher operational costs.
Hybrid and multi-service strategies work: You don't have to choose just one—many organizations successfully use multiple services for different workloads.
Plan for growth: Choose a service that can grow with your needs, or ensure you have a clear migration path to a more capable service.
Security and compliance are paramount: Ensure your chosen service meets your security and regulatory requirements from day one.

The Azure container ecosystem continues to evolve rapidly, with new features and improvements released regularly. Regardless of which service you choose today, Microsoft's investment in containers ensures you're building on a solid, future-proof foundation. Take time to evaluate your requirements carefully, start with a proof of concept, and don't be afraid to iterate as you learn more about your workload's needs.

Your journey to containerization is an evolution, not a revolution. Choose the service that best fits your current state, keep learning, and adjust your strategy as your organization's container maturity grows.

Azure Kubernetes Service (AKS) Network Policies: A Comprehensive Guide

Mikael Krief — Wed, 19 Nov 2025 09:38:01 +0000

Network security is a critical component of any Kubernetes deployment, especially in enterprise environments where regulatory compliance and data protection are paramount. Network policies in Kubernetes provide a way to control traffic flow between pods and network endpoints at the application layer, similar to how security groups and firewalls work for virtual machines.

Azure Kubernetes Service (AKS) supports multiple network policy implementations, each with its own strengths, features, and use cases. Understanding the differences between these options is crucial for designing secure, performant, and compliant Kubernetes workloads.

In this article, we'll explore the different network policy options available for AKS:

Azure Network Policy Manager (Azure NPM): Microsoft's native solution for basic network policies
Calico: A popular open-source network policy engine with advanced features
Cilium: A modern, eBPF-based networking and security solution

We'll compare these options across various dimensions including:

Feature sets: What capabilities each solution provides
Performance: How each solution impacts cluster performance
Ease of use: Installation, configuration, and management complexity
Integration: How well each solution integrates with Azure services
Use cases: When to choose each option

By the end of this article, you'll have a clear understanding of which network policy solution best fits your requirements and how to implement it in your AKS cluster.

Understanding Kubernetes Network Policies

Before diving into the specific implementations, it's important to understand what Kubernetes network policies are and how they work.

What are Network Policies?

Kubernetes Network Policies are specifications that define how groups of pods can communicate with each other and with other network endpoints. They operate at Layer 3 and Layer 4 of the OSI model, controlling traffic based on:

Pod selectors: Which pods the policy applies to
Ingress rules: What incoming traffic is allowed
Egress rules: What outgoing traffic is allowed
Namespaces: Scope of the policy application
IP blocks: CIDR ranges for external endpoints

Default Behavior

By default, Kubernetes allows all traffic between all pods in a cluster. This "allow-all" behavior is convenient for development but poses security risks in production environments. Network policies enable you to implement a "deny-all-by-default" approach, explicitly allowing only necessary traffic.

Basic Network Policy Example

Here's a simple example of a Kubernetes network policy:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: frontend-policy
  namespace: production
spec:
  podSelector:
    matchLabels:
      role: frontend
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: backend
    ports:
    - protocol: TCP
      port: 8080
  egress:
  - to:
    - podSelector:
        matchLabels:
          role: backend
    ports:
    - protocol: TCP
      port: 3306

This policy applies to pods with the label role: frontend and:

Allows ingress traffic only from pods labeled role: backend on port 8080
Allows egress traffic only to pods labeled role: backend on port 3306

AKS Network Policy Options

1. Azure Network Policy Manager (Azure NPM)

Azure Network Policy Manager is Microsoft's native implementation of Kubernetes network policies for AKS. It's built on Azure's Virtual Network capabilities and integrates tightly with Azure networking infrastructure.

Architecture

Azure NPM uses Azure Virtual Network capabilities to implement network policies:

Translates Kubernetes network policies into Azure Network Security Group (NSG) rules
Leverages Azure's data plane for policy enforcement
Operates at the node level using iptables rules

Key Features

Advantages:

Native Azure integration: Seamless integration with Azure services and networking
No additional components: Built into AKS, no separate installation required
Azure support: Fully supported by Microsoft Azure support
Basic functionality: Covers standard Kubernetes network policy use cases
Simple setup: Easy to enable on new or existing clusters
Cost-effective: No additional licensing costs

Limitations:

Basic feature set: Limited to standard Kubernetes network policies
No advanced features: Lacks features like DNS-based policies, application-layer filtering
Performance considerations: May have overhead due to iptables implementation
Limited observability: Basic logging and monitoring capabilities
IPv4 only: Currently supports only IPv4 addresses

When to Use Azure NPM

Azure Network Policy Manager is ideal when:

You need basic network policy functionality
You want Microsoft support for the entire networking stack
You're building a new cluster and want to start simple
Your team is already familiar with Azure networking concepts
You don't require advanced features like DNS-based policies
You want to minimize third-party dependencies

Enabling Azure NPM

To create an AKS cluster with Azure Network Policy Manager:

# Create a new AKS cluster with Azure NPM
az aks create \
  --resource-group myResourceGroup \
  --name myAKSCluster \
  --network-plugin azure \
  --network-policy azure \
  --node-count 3

Explanation: Creates an AKS cluster with:

--network-plugin azure: Uses Azure CNI networking (required for Azure NPM)
--network-policy azure: Enables Azure Network Policy Manager
--node-count 3: Creates a 3-node cluster for high availability

Terraform equivalent:

resource "azurerm_kubernetes_cluster" "main" {
  name                = "myAKSCluster"
  location            = azurerm_resource_group.main.location
  resource_group_name = azurerm_resource_group.main.name
  dns_prefix          = "myakscluster"

  default_node_pool {
    name       = "default"
    node_count = 3
    vm_size    = "Standard_D2_v2"
  }

  network_profile {
    network_plugin = "azure"
    network_policy = "azure"
  }

  identity {
    type = "SystemAssigned"
  }
}

For existing clusters, you cannot change the network policy after creation. You would need to create a new cluster with the desired network policy.

Example Azure NPM Policy

# Deny all ingress traffic by default
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
---
# Allow specific traffic to database
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-app-to-db
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: database
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: backend
    ports:
    - protocol: TCP
      port: 5432

2. Calico Network Policy

Calico is one of the most popular and mature network policy implementations in the Kubernetes ecosystem. It's an open-source project maintained by Tigera that provides both networking and network policy capabilities.

Architecture

Calico uses a different approach compared to Azure NPM:

Felix agent runs on each node to enforce policies
Uses eBPF or iptables for data plane enforcement
etcd or Kubernetes API server for policy storage
BGP for routing (when used as a CNI)

Key Features

Advantages:

Rich feature set: Advanced features beyond standard Kubernetes network policies
High performance: eBPF data plane option for better performance
DNS-based policies: Can create policies based on DNS names
Global network policies: Apply policies across all namespaces
Network sets: Define reusable IP/CIDR groups
Observability: Built-in flow logs and detailed metrics
Encryption: Support for WireGuard encryption
Enterprise support: Commercial support available from Tigera
Mature and proven: Used in production by many organizations
Active community: Large community and extensive documentation

Advanced Features:

Application Layer Policies: Layer 7 policy enforcement
Hierarchical policies: Create policy tiers with different priorities
Service Graph: Visual representation of service-to-service communications
Compliance reporting: Built-in compliance reports
Threat detection: Integration with threat intelligence feeds

Limitations:

Additional complexity: More components to manage and monitor
Learning curve: Requires understanding Calico-specific concepts
Resource overhead: Additional pods and agents consume cluster resources
Updates: Need to manage Calico version updates separately from AKS

When to Use Calico

Calico is ideal when:

You need advanced network policy features beyond standard Kubernetes
You require DNS-based or FQDN-based policies
You want detailed network flow logs and observability
You need to implement zero-trust network architecture
You require encryption for pod-to-pod communication
You have compliance requirements that need detailed auditing
Your team has experience with Calico or can invest in learning it

Installing Calico on AKS

To create an AKS cluster with Calico:

# Create AKS cluster with Calico network policy
az aks create \
  --resource-group myResourceGroup \
  --name myAKSCluster \
  --network-plugin azure \
  --network-policy calico \
  --node-count 3

Explanation: Creates an AKS cluster with:

--network-plugin azure: Uses Azure CNI for networking
--network-policy calico: Enables Calico for network policy enforcement
Calico will be installed as DaemonSets in the kube-system namespace

Terraform equivalent:

resource "azurerm_kubernetes_cluster" "main" {
  name                = "myAKSCluster"
  location            = azurerm_resource_group.main.location
  resource_group_name = azurerm_resource_group.main.name
  dns_prefix          = "myakscluster"

  default_node_pool {
    name       = "default"
    node_count = 3
    vm_size    = "Standard_D2_v2"
  }

  network_profile {
    network_plugin = "azure"
    network_policy = "calico"
  }

  identity {
    type = "SystemAssigned"
  }
}

Verify Calico installation:

# Check Calico pods
kubectl get pods -n kube-system | grep calico

Explanation: Lists all pods in the kube-system namespace that contain "calico" in their name. You should see calico-node pods running on each node.

Example Calico Policies

Standard Kubernetes Network Policy:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: production
spec:
  podSelector:
    matchLabels:
      tier: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          tier: frontend
    ports:
    - protocol: TCP
      port: 8080

Calico Global Network Policy:

apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
  name: deny-egress-external
spec:
  selector: has(role)
  types:
  - Egress
  egress:
  # Allow DNS
  - action: Allow
    protocol: UDP
    destination:
      ports:
      - 53
  # Allow internal cluster traffic
  - action: Allow
    destination:
      nets:
      - 10.0.0.0/8
  # Deny everything else
  - action: Deny

DNS-based Policy:

apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
  name: allow-external-apis
  namespace: production
spec:
  selector: app == 'backend'
  types:
  - Egress
  egress:
  # Allow access to specific external services by DNS
  - action: Allow
    protocol: TCP
    destination:
      domains:
      - "api.stripe.com"
      - "*.azure.com"
      ports:
      - 443

Network Sets for IP Management:

apiVersion: projectcalico.org/v3
kind: GlobalNetworkSet
metadata:
  name: allowed-external-ips
spec:
  nets:
  - 203.0.113.0/24
  - 198.51.100.0/24
---
apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
  name: allow-to-external-ips
  namespace: production
spec:
  selector: app == 'web'
  types:
  - Egress
  egress:
  - action: Allow
    destination:
      selector: global() == 'allowed-external-ips'

Calico Observability

Calico provides enhanced observability features:

# Install calicoctl (Calico CLI tool)
curl -L https://github.com/projectcalico/calico/releases/latest/download/calicoctl-linux-amd64 -o calicoctl
chmod +x calicoctl
sudo mv calicoctl /usr/local/bin/

# View network policy status
calicoctl get networkpolicy -A -o wide

# View global network policies
calicoctl get globalnetworkpolicy -o wide

# Check policy order and priority
calicoctl get networkpolicy --all-namespaces -o yaml

Explanation: These commands help you inspect and troubleshoot Calico network policies. calicoctl is the command-line tool for managing Calico resources.

Enable flow logs:

apiVersion: projectcalico.org/v3
kind: FelixConfiguration
metadata:
  name: default
spec:
  flowLogsEnableHostEndpoint: true
  flowLogsFileEnabled: true
  flowLogsFileIncludeLabels: true
  flowLogsFileIncludePolicies: true
  dnsLogsFileEnabled: true

3. Cilium Network Policy

Cilium is a modern networking and security solution built on eBPF (extended Berkeley Packet Filter) technology. It's gaining popularity due to its high performance and advanced features.

Architecture

Cilium's architecture is fundamentally different from traditional network policy implementations:

eBPF-based: Uses eBPF programs loaded into the Linux kernel for packet filtering
Identity-based: Uses security identities instead of IP addresses
API-aware: Can filter based on HTTP, gRPC, and other application protocols
Cilium Agent: Runs on each node to manage eBPF programs
Cilium Operator: Manages cluster-wide resources

Key Features

Advantages:

Exceptional performance: eBPF provides near-native network performance
Layer 7 policies: Filter traffic based on HTTP methods, paths, headers
API-aware security: Understand and filter application-layer protocols
Identity-based: More flexible than IP-based policies
Service mesh capabilities: Can replace or complement service meshes
Network visibility: Deep network and application visibility with Hubble
Transparent encryption: Automatic encryption of all pod traffic
Multi-cluster: Native support for multi-cluster networking
Modern architecture: Built for cloud-native from the ground up
Growing ecosystem: Rapid development and feature additions

Advanced Features:

Hubble: Network and security observability platform
BGP support: Advanced routing capabilities
Bandwidth management: QoS and traffic shaping
Network policies for services: Apply policies to Kubernetes services
Kafka/DNS protocol enforcement: Application-specific policy enforcement

Limitations:

Kernel requirements: Requires relatively modern Linux kernels (4.9+)
Complexity: More complex architecture and concepts
Maturity: Newer than Calico, less production track record in AKS
Manual installation: Not natively supported by AKS, requires manual installation
Learning curve: Requires understanding of eBPF and Cilium concepts
Troubleshooting: Can be more difficult to debug eBPF issues

When to Use Cilium

Cilium is ideal when:

You need maximum network performance
You require Layer 7 (HTTP/gRPC) policy enforcement
You want modern, API-aware security
You need advanced observability with Hubble
You're building microservices that need fine-grained policies
You want to implement a zero-trust network architecture
You have the expertise to manage a more complex system
Performance is a critical requirement

Installing Cilium on AKS

Cilium is not natively supported by AKS through the --network-policy flag, so it requires manual installation. Here's how to install it:

Step 1: Create AKS cluster without network policy

# Create AKS cluster with Azure CNI, no network policy yet
az aks create \
  --resource-group myResourceGroup \
  --name myAKSCluster \
  --network-plugin azure \
  --node-count 3 \
  --generate-ssh-keys

Explanation: Creates an AKS cluster with Azure CNI networking but without any network policy engine. We'll install Cilium afterward.

Terraform equivalent:

resource "azurerm_kubernetes_cluster" "main" {
  name                = "myAKSCluster"
  location            = azurerm_resource_group.main.location
  resource_group_name = azurerm_resource_group.main.name
  dns_prefix          = "myakscluster"

  default_node_pool {
    name       = "default"
    node_count = 3
    vm_size    = "Standard_D2_v2"
  }

  network_profile {
    network_plugin = "azure"
    # No network_policy specified
  }

  identity {
    type = "SystemAssigned"
  }
}

Step 2: Install Cilium using Helm

# Get cluster credentials
az aks get-credentials --resource-group myResourceGroup --name myAKSCluster

Explanation: Downloads the cluster configuration and credentials to your local kubeconfig file.

# Add Cilium Helm repository
helm repo add cilium https://helm.cilium.io/
helm repo update

Explanation: Adds the Cilium Helm chart repository and updates the local cache of chart information.

# Install Cilium
helm install cilium cilium/cilium \
  --version 1.14.5 \
  --namespace kube-system \
  --set azure.enabled=true \
  --set azure.resourceGroup=myResourceGroup \
  --set azure.subscriptionID="YOUR_SUBSCRIPTION_ID" \
  --set azure.tenantID="YOUR_TENANT_ID" \
  --set tunnel=disabled \
  --set ipam.mode=azure \
  --set enableIPv4Masquerade=false \
  --set nodeinit.enabled=true

Explanation: Installs Cilium with Azure-specific configurations:

azure.enabled=true: Enables Azure integration
tunnel=disabled: Uses Azure routing instead of overlay networking
ipam.mode=azure: Uses Azure CNI for IP address management
enableIPv4Masquerade=false: Disables masquerading since Azure handles routing
nodeinit.enabled=true: Initializes nodes with required configurations

Terraform equivalent (using Helm provider):

resource "helm_release" "cilium" {
  name       = "cilium"
  repository = "https://helm.cilium.io/"
  chart      = "cilium"
  version    = "1.14.5"
  namespace  = "kube-system"

  set {
    name  = "azure.enabled"
    value = "true"
  }

  set {
    name  = "azure.resourceGroup"
    value = azurerm_resource_group.main.name
  }

  set {
    name  = "azure.subscriptionID"
    value = data.azurerm_subscription.current.subscription_id
  }

  set {
    name  = "azure.tenantID"
    value = data.azurerm_subscription.current.tenant_id
  }

  set {
    name  = "tunnel"
    value = "disabled"
  }

  set {
    name  = "ipam.mode"
    value = "azure"
  }

  set {
    name  = "enableIPv4Masquerade"
    value = "false"
  }

  set {
    name  = "nodeinit.enabled"
    value = "true"
  }

  depends_on = [azurerm_kubernetes_cluster.main]
}

data "azurerm_subscription" "current" {}

Step 3: Verify installation

# Check Cilium pods
kubectl get pods -n kube-system -l k8s-app=cilium

# Check Cilium status
cilium status --wait

# Run connectivity test
cilium connectivity test

Explanation: These commands verify that Cilium is installed correctly and running on all nodes. The connectivity test performs comprehensive checks of network functionality.

Example Cilium Policies

Standard Kubernetes Network Policy:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: production
spec:
  podSelector:
    matchLabels:
      tier: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          tier: frontend
    ports:
    - protocol: TCP
      port: 8080

Cilium Layer 7 HTTP Policy:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: allow-specific-http-methods
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      app: api-server
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: frontend
    toPorts:
    - ports:
      - port: "8080"
        protocol: TCP
      rules:
        http:
        - method: "GET"
          path: "/api/.*"
        - method: "POST"
          path: "/api/users"

DNS/FQDN-based Policy:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: allow-external-apis
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      app: backend
  egress:
  - toFQDNs:
    - matchPattern: "*.azure.com"
    - matchName: "api.github.com"
    toPorts:
    - ports:
      - port: "443"
        protocol: TCP

Layer 7 gRPC Policy:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: grpc-policy
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      app: grpc-server
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: grpc-client
    toPorts:
    - ports:
      - port: "50051"
        protocol: TCP
      rules:
        http:
        - method: "POST"
          path: "/order.OrderService/GetOrder"
        - method: "POST"
          path: "/order.OrderService/CreateOrder"
        - method: "POST"
          path: "/order.OrderService/ListOrders"

Service-based Policy:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: allow-to-service
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      app: client
  egress:
  - toServices:
    - k8sService:
        serviceName: backend-service
        namespace: production

Cilium Observability with Hubble

Hubble is Cilium's observability platform:

# Enable Hubble
helm upgrade cilium cilium/cilium \
  --namespace kube-system \
  --reuse-values \
  --set hubble.relay.enabled=true \
  --set hubble.ui.enabled=true

Explanation: Enables Hubble UI and relay for network observability. This provides a graphical interface to visualize network traffic and policies.

# Install Hubble CLI
export HUBBLE_VERSION=$(curl -s https://raw.githubusercontent.com/cilium/hubble/master/stable.txt)
curl -L --remote-name-all https://github.com/cilium/hubble/releases/download/$HUBBLE_VERSION/hubble-linux-amd64.tar.gz{,.sha256sum}
sha256sum --check hubble-linux-amd64.tar.gz.sha256sum
sudo tar xzvfC hubble-linux-amd64.tar.gz /usr/local/bin

Explanation: Downloads and installs the Hubble CLI tool for querying network flows from the command line.

# Port forward to Hubble UI
kubectl port-forward -n kube-system svc/hubble-ui 12000:80

Explanation: Makes the Hubble UI accessible at http://localhost:12000 for visualizing network traffic.

Query network flows:

# Observe flows in real-time
hubble observe

# Observe flows for specific namespace
hubble observe --namespace production

# Observe flows with specific labels
hubble observe --from-label app=frontend --to-label app=backend

# Observe denied flows
hubble observe --verdict DROPPED

Comparison Matrix

Here's a comprehensive comparison of the three network policy options:

Feature	Azure NPM	Calico	Cilium
Native AKS Support	✅ Yes	✅ Yes	❌ No (manual install)
Ease of Setup	⭐⭐⭐⭐⭐ Very Easy	⭐⭐⭐⭐ Easy	⭐⭐⭐ Moderate
Standard K8s Policies	✅ Yes	✅ Yes	✅ Yes
Layer 7 Policies	❌ No	⚠️ Limited	✅ Full support
DNS/FQDN Policies	❌ No	✅ Yes	✅ Yes
Global Policies	❌ No	✅ Yes	✅ Yes
Performance	⭐⭐⭐ Good	⭐⭐⭐⭐ Very Good	⭐⭐⭐⭐⭐ Excellent
Observability	⭐⭐ Basic	⭐⭐⭐⭐ Advanced	⭐⭐⭐⭐⭐ Superior
Learning Curve	⭐⭐⭐⭐⭐ Easy	⭐⭐⭐ Moderate	⭐⭐ Steep
Enterprise Support	✅ Microsoft	✅ Tigera	✅ Isovalent
Encryption	❌ No	✅ WireGuard	✅ IPSec/WireGuard
Multi-cluster	❌ Limited	✅ Yes	✅ Yes
Service Mesh Features	❌ No	⚠️ Limited	✅ Yes
Resource Usage	⭐⭐⭐⭐ Low	⭐⭐⭐ Moderate	⭐⭐⭐ Moderate
Maturity in AKS	⭐⭐⭐⭐⭐ High	⭐⭐⭐⭐⭐ High	⭐⭐⭐ Growing
Community	Azure community	⭐⭐⭐⭐⭐ Large	⭐⭐⭐⭐ Growing
Cost	Free	Free (OSS)	Free (OSS)

Implementation Best Practices

1. Start with Deny-All Policy

Regardless of which solution you choose, start with a default deny-all policy:

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

This creates a secure-by-default posture where you explicitly allow only necessary traffic.

2. Implement Least Privilege Access

Only allow the minimum necessary access:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-policy
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  - Egress
  ingress:
  # Only allow from frontend
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080
  egress:
  # Only allow to database
  - to:
    - podSelector:
        matchLabels:
          app: database
    ports:
    - protocol: TCP
      port: 5432
  # Allow DNS
  - to:
    - namespaceSelector:
        matchLabels:
          name: kube-system
    ports:
    - protocol: UDP
      port: 53

3. Use Namespaces for Isolation

Organize workloads into namespaces and use namespace selectors:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-same-namespace
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector: {}

4. Always Allow Essential Traffic

Don't forget to allow essential cluster traffic:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  # Allow DNS
  - to:
    - namespaceSelector:
        matchLabels:
          name: kube-system
    - podSelector:
        matchLabels:
          k8s-app: kube-dns
    ports:
    - protocol: UDP
      port: 53

5. Label Resources Consistently

Use consistent labeling for effective policy management:

# Good labeling strategy
metadata:
  labels:
    app: backend
    tier: api
    environment: production
    team: platform

6. Test Policies in Non-Production First

Always test network policies in development/staging before production:

# Create test namespace
kubectl create namespace policy-test

# Deploy test application
kubectl apply -f test-app.yaml -n policy-test

# Apply policy
kubectl apply -f test-policy.yaml -n policy-test

# Test connectivity
kubectl exec -n policy-test test-pod -- curl http://backend-service

7. Monitor and Audit Policies

Implement monitoring for policy violations:

# For Calico - view denied flows
calicoctl get felixconfiguration default -o yaml

# For Cilium - observe dropped packets
hubble observe --verdict DROPPED

# Check policy logs in Azure Monitor
az monitor log-analytics query \
  --workspace YOUR_WORKSPACE_ID \
  --analytics-query "KubePodInventory | where Namespace == 'production'"

8. Document Your Policies

Maintain documentation for your network policies:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: frontend-policy
  namespace: production
  annotations:
    description: "Allows frontend pods to communicate with backend API"
    owner: "platform-team@company.com"
    reviewed: "2024-01-15"
spec:
  # ... policy spec

Testing Network Policies

Basic Connectivity Testing

Create test pods to verify policy enforcement:

# test-client.yaml
apiVersion: v1
kind: Pod
metadata:
  name: test-client
  namespace: production
  labels:
    app: test
spec:
  containers:
  - name: netshoot
    image: nicolaka/netshoot
    command: ["sleep", "3600"]
---
# test-server.yaml
apiVersion: v1
kind: Pod
metadata:
  name: test-server
  namespace: production
  labels:
    app: backend
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80

Test connectivity:

# Deploy test pods
kubectl apply -f test-client.yaml
kubectl apply -f test-server.yaml

# Get server IP
SERVER_IP=$(kubectl get pod test-server -n production -o jsonpath='{.status.podIP}')

# Test before policy (should work)
kubectl exec -n production test-client -- curl -m 5 http://$SERVER_IP

# Apply restrictive policy
kubectl apply -f restrictive-policy.yaml

# Test after policy (should fail if policy blocks it)
kubectl exec -n production test-client -- curl -m 5 http://$SERVER_IP

Policy Validation Tools

Use policy validation tools:

# For Calico - policy validation
calicoctl get networkpolicy --all-namespaces
calicoctl get globalnetworkpolicy

# For Cilium - policy validation
cilium policy validate
cilium endpoint list

# Check policy effectiveness
kubectl get networkpolicy --all-namespaces
kubectl describe networkpolicy <policy-name> -n <namespace>

Troubleshooting Network Policies

Common Issues and Solutions

Issue 1: Policy Not Being Enforced

# Check if network policy is applied
kubectl get networkpolicy -n <namespace>

# Describe the policy
kubectl describe networkpolicy <policy-name> -n <namespace>

# For Calico - check Felix logs
kubectl logs -n kube-system -l k8s-app=calico-node

# For Cilium - check agent logs
kubectl logs -n kube-system -l k8s-app=cilium

Issue 2: Pods Cannot Connect

# Verify pod labels
kubectl get pods --show-labels -n <namespace>

# Check if pod matches policy selector
kubectl get networkpolicy <policy-name> -n <namespace> -o yaml

# Test DNS resolution
kubectl exec <pod-name> -n <namespace> -- nslookup kubernetes.default

# Check if DNS is allowed in policy
kubectl get networkpolicy -n <namespace> -o yaml | grep -A 10 egress

Issue 3: Performance Degradation

# For Calico - check Felix performance metrics
kubectl get felixconfiguration default -o yaml

# For Cilium - check eBPF program performance
cilium metrics list

# Check node resource usage
kubectl top nodes
kubectl top pods -n kube-system

Debugging Tools

Network debugging pod:

apiVersion: v1
kind: Pod
metadata:
  name: netdebug
spec:
  containers:
  - name: netshoot
    image: nicolaka/netshoot
    command: ["sleep", "3600"]

# Deploy and use debugging pod
kubectl apply -f netdebug.yaml

# Available tools in netshoot:
kubectl exec netdebug -- ping <ip>
kubectl exec netdebug -- traceroute <ip>
kubectl exec netdebug -- nslookup <hostname>
kubectl exec netdebug -- curl -v <url>
kubectl exec netdebug -- tcpdump -i any port 80

Migration Strategies

Migrating from No Policy to Network Policies

Step 1: Audit existing traffic

# Enable flow logs (if using Calico or Cilium)
# For Calico:
kubectl patch felixconfiguration default --type merge -p '{"spec":{"flowLogsEnableHostEndpoint":true}}'

# For Cilium with Hubble:
hubble observe --all

Step 2: Create allow-all policy

# Baseline policy that allows everything (no disruption)
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all-temporary
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - {}
  egress:
  - {}

Step 3: Gradually restrict

# Phase 1: Deny all, but allow same namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-same-namespace
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector: {}
---
# Phase 2: Add specific policies for each service
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-policy
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend
  # ... specific rules

Migrating Between Policy Engines

From Azure NPM to Calico:

Create a new cluster with Calico
Migrate workloads using blue-green deployment
Validate policies work correctly
Switch traffic to new cluster
Decommission old cluster

From Calico to Cilium:

Back up existing Calico policies
Install Cilium alongside Calico (if possible for testing)
Convert policies to Cilium format
Test thoroughly in non-production environment
Perform controlled migration

Real-World Use Cases

Use Case 1: Multi-Tier Web Application

Architecture:

Frontend (React app)
Backend API (Node.js)
Database (PostgreSQL)
Redis cache

Network Policy Strategy:

# Frontend can access backend API only
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: frontend-policy
  namespace: production
spec:
  podSelector:
    matchLabels:
      tier: frontend
  policyTypes:
  - Egress
  egress:
  - to:
    - podSelector:
        matchLabels:
          tier: backend
    ports:
    - protocol: TCP
      port: 3000
  - to:
    - namespaceSelector: {}
      podSelector:
        matchLabels:
          k8s-app: kube-dns
    ports:
    - protocol: UDP
      port: 53
---
# Backend can access database and Redis only
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-policy
  namespace: production
spec:
  podSelector:
    matchLabels:
      tier: backend
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          tier: frontend
    ports:
    - protocol: TCP
      port: 3000
  egress:
  - to:
    - podSelector:
        matchLabels:
          tier: database
    ports:
    - protocol: TCP
      port: 5432
  - to:
    - podSelector:
        matchLabels:
          tier: cache
    ports:
    - protocol: TCP
      port: 6379
  - to:
    - namespaceSelector: {}
      podSelector:
        matchLabels:
          k8s-app: kube-dns
    ports:
    - protocol: UDP
      port: 53
---
# Database accepts connections from backend only
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: database-policy
  namespace: production
spec:
  podSelector:
    matchLabels:
      tier: database
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          tier: backend
    ports:
    - protocol: TCP
      port: 5432

Use Case 2: Microservices with Service Mesh

For microservices architectures with Cilium:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: order-service-policy
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      app: order-service
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: api-gateway
    toPorts:
    - ports:
      - port: "8080"
        protocol: TCP
      rules:
        http:
        - method: "GET"
          path: "/api/orders/.*"
        - method: "POST"
          path: "/api/orders"
        - method: "PUT"
          path: "/api/orders/.*"
  egress:
  - toEndpoints:
    - matchLabels:
        app: inventory-service
    toPorts:
    - ports:
      - port: "8080"
        protocol: TCP
      rules:
        http:
        - method: "GET"
          path: "/api/inventory/.*"
  - toFQDNs:
    - matchPattern: "*.database.azure.com"
    toPorts:
    - ports:
      - port: "5432"
        protocol: TCP

Use Case 3: Compliance and Regulatory Requirements

For environments requiring strict compliance:

# PCI-DSS compliant policy for payment service
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: payment-service-policy
  namespace: pci-compliant
  annotations:
    compliance: "PCI-DSS v3.2.1"
    description: "Isolates payment processing workloads"
spec:
  podSelector:
    matchLabels:
      compliance: pci-dss
  policyTypes:
  - Ingress
  - Egress
  ingress:
  # Only allow from authenticated API gateway
  - from:
    - podSelector:
        matchLabels:
          app: api-gateway
          auth: enabled
    ports:
    - protocol: TCP
      port: 8443
  egress:
  # Only allow to payment provider APIs
  - to:
    - podSelector:
        matchLabels:
          type: payment-provider
    ports:
    - protocol: TCP
      port: 443
  # Allow logging to compliance log collector
  - to:
    - podSelector:
        matchLabels:
          app: log-collector
          compliance: enabled
    ports:
    - protocol: TCP
      port: 9200

Conclusion

Choosing the right network policy solution for your AKS cluster is a critical decision that impacts security, performance, and operational complexity. Let's summarize the key considerations:

Quick Decision Guide

Choose Azure Network Policy Manager if:

You're new to Kubernetes network policies
You want simple, Microsoft-supported solution
You need only basic network policy features
You prefer minimal operational overhead
Your team is already familiar with Azure networking

Choose Calico if:

You need advanced network policy features
You require DNS/FQDN-based policies
You need detailed observability and logging
You want a mature, proven solution
You have compliance requirements needing extensive auditing
You may need to migrate to other cloud providers or on-premises

Choose Cilium if:

Performance is a critical requirement
You need Layer 7 HTTP/gRPC policy enforcement
You want modern, API-aware security
You need advanced observability with Hubble
You're building a microservices architecture
You have expertise to manage a more complex system
You want cutting-edge technology and features

Key Takeaways

Start Simple: Begin with basic policies and gradually increase complexity as you understand your traffic patterns
Test Thoroughly: Always test network policies in non-production environments before applying to production
Monitor Continuously: Implement comprehensive monitoring to detect policy violations and unexpected behavior
Document Everything: Maintain clear documentation of your network policies and their purposes
Plan for Scale: Consider how your policy solution will scale as your cluster grows
Security First: Implement a deny-by-default strategy and explicitly allow only necessary traffic
Regular Audits: Periodically review and update network policies to ensure they remain relevant and effective

Future Trends

The Kubernetes network policy ecosystem continues to evolve:

eBPF adoption: More solutions leveraging eBPF for better performance
Service mesh integration: Tighter integration between network policies and service meshes
Zero trust networking: Enhanced support for zero-trust security models
Multi-cluster policies: Better support for policies spanning multiple clusters
AI/ML-based policies: Intelligent policies that adapt based on traffic patterns

Regardless of which solution you choose, implementing network policies is essential for securing your AKS workloads. By following the best practices outlined in this article and choosing the solution that best fits your requirements, you can build a secure, compliant, and performant Kubernetes environment.

Remember: network policies are just one layer of security. Combine them with other security measures like RBAC, Pod Security Standards, image scanning, and secret management for defense-in-depth security.

References

Configuring Azure App Service Authentication with Azure Entra ID to Exclude API Routes While Protecting the UI

Mikael Krief — Thu, 13 Nov 2025 10:21:51 +0000

I was building a Node.js web application for managing files in Azure Blob Storage, deployed to an Azure App Service (Linux). The application consisted of:

A backend API built with Express.js and the Azure Storage SDK
A frontend UI using Bootstrap and DataTables
Azure App Service Authentication with Azure Entra ID

Everything worked fine in my local and staging environments.

The Problem

However, when I deployed to production with Azure Entra ID authentication enabled, I encountered a critical issue:

File uploads were failing with HTTP 403 (Forbidden) errors, even though listing and deleting files worked perfectly.

The root cause? Azure Entra ID authentication was intercepting all requests, including API calls, and blocking unauthenticated programmatic uploads. My goal was to:

Protect the UI with Entra ID authentication (redirect users to login)
Allow API routes (/api/*) to be accessed without authentication for file operations
Keep the backend using Azure Storage Access Keys (not user tokens)

Solutions Explored

Solution 1: Custom Middleware Authentication (Failed)

My first attempt was to implement custom middleware in Express to handle authentication:

// Custom middleware approach (didn't work)
function requireAuthForUI(req, res, next) {
  if (req.path.startsWith('/api')) {
    return next(); // Skip auth for API
  }

  if (!req.headers['x-ms-client-principal']) {
    return res.redirect('/.auth/login/aad');
  }

  next();
}

app.use(requireAuthForUI);

Problems encountered:

Created redirect loops (HTTP 431)
/.auth/login/aad returned "Route not found" because Azure Entra ID authentication wasn't active at the platform level
Custom middleware interfered with Azure Entra ID authentication's built-in routing

Lesson learned: Don't try to implement authentication logic in your Node.js app when using Azure Entra ID authentication. The platform must handle authentication before requests reach your application code.

Solution 2: Patching authsettingsV2 via Azure CLI (Failed)

I attempted to configure Easy Auth by directly patching the authsettingsV2 API using Azure CLI:

az rest --method PATCH \
  --url "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/Microsoft.Web/sites/{appName}/config/authsettingsV2?api-version=2022-03-01" \
  --body @auth.json

Problems encountered:

UnsupportedMediaType errors due to JSON formatting issues
InvalidRequestContent when trying different approaches
Complex JSON structure with nested properties made it error-prone

References:

Azure App Service Authentication REST API

Solution 3: File-Based Configuration (Success)

The winning solution was to use file-based Azure Entra ID authentication configuration by creating a .auth/config.json file in the repository.

Key advantages of this approach:

Configuration as Code: The authentication configuration lives in your repository alongside your application code
Version controlled: Track changes, rollback if needed, and review configurations through pull requests
Easy to extend: Need to add another API route (e.g., /admin-api)? Simply add it to excludedPaths in the config file and redeploy
Environment consistency: Deploy the same configuration across dev, staging, and production
No portal dependency: No need to manually configure authentication settings through the Azure Portal for each environment

The Implementation

Step 1: Create `.auth/config.json`

I created a configuration file that:

Enables Azure Entra ID authentication at the platform level
Redirects unauthenticated users to Entra ID login for the UI
Excludes /api and /api/* paths from authentication

{
  "platform": {
    "enabled": true
  },
  "globalValidation": {
    "requireAuthentication": true,
    "unauthenticatedClientAction": "RedirectToLoginPage",
    "excludedPaths": [
      "/api",
      "/api/*"
    ]
  },
  "identityProviders": {
    "azureActiveDirectory": {
      "enabled": true,
      "registration": {
        "clientIdSettingName": "MICROSOFT_PROVIDER_CLIENT_ID",
        "clientSecretSettingName": "MICROSOFT_PROVIDER_AUTHENTICATION_SECRET",
        "openIdIssuer": "https://login.microsoftonline.com/{tenant-id}/v2.0"
      }
    }
  },
  "login": {
    "tokenStore": {
      "enabled": true
    }
  },
  "httpSettings": {
    "requireHttps": true,
    "routes": {
      "apiPrefix": "/.auth"
    }
  }
}

Key configuration points:

excludedPaths: Tells Azure Entra ID authentication to skip authentication for /api routes
unauthenticatedClientAction: "RedirectToLoginPage": Protects the UI by redirecting to login
openIdIssuer: Use login.microsoftonline.com (not sts.windows.net) for proper v2.0 endpoint validation
Settings references: Use app settings for sensitive values instead of hardcoding

Step 2: Configure the Configuration File Path

To enable file-based authentication, you need to tell Azure App Service where to find your configuration file. There are two main approaches:

Option A: Using App Settings (Recommended)

In Azure Portal (or via CLI), add the WEBSITE_AUTH_CONFIG_DIR application setting:

WEBSITE_AUTH_CONFIG_DIR=.auth
MICROSOFT_PROVIDER_CLIENT_ID=<your-app-registration-client-id>
MICROSOFT_PROVIDER_AUTHENTICATION_SECRET=<your-client-secret>

This tells Azure App Service to load authentication configuration from the .auth directory in your deployment package.

Option B: Using platform.configFilePath in ARM Template

Alternatively, you can set the configuration path directly in the App Service resource configuration using ARM Template or Azure Resource Explorer:

ARM Template Example:

{
  "type": "Microsoft.Web/sites/config",
  "apiVersion": "2022-03-01",
  "name": "[concat(parameters('siteName'), '/authsettingsV2')]",
  "dependsOn": [
    "[resourceId('Microsoft.Web/sites', parameters('siteName'))]"
  ],
  "properties": {
    "platform": {
      "enabled": true,
      "configFilePath": ".auth/config.json"
    }
  }
}

Azure Resource Explorer Steps:

Navigate to Azure Resource Explorer
Browse to: subscriptions/{subscription-id}/resourceGroups/{resource-group}/providers/Microsoft.Web/sites/{app-name}/config/authsettingsV2
Click Edit and add or update the platform section:

{
  "properties": {
    "platform": {
      "enabled": true,
      "configFilePath": ".auth/config.json"
    }
  }
}

Click PUT to apply the changes

Key differences:

Method	Scope	Best for
`WEBSITE_AUTH_CONFIG_DIR`	Points to a directory; App Service looks for `config.json` inside	Simple scenarios, CI/CD pipelines
`platform.configFilePath`	Points to a specific file path	Fine-grained control, IaC deployments

Important notes:

The path is relative to your application root (/home/site/wwwroot on Linux)
Don't forget to also set MICROSOFT_PROVIDER_CLIENT_ID and MICROSOFT_PROVIDER_AUTHENTICATION_SECRET as app settings
Restart your App Service after making these changes

Step 3: Remove Custom Middleware

I removed all custom authentication middleware from server.js to avoid interference:

// Removed this:
// app.use(requireAuthForUI);

// Let Azure Entra ID authentication handle everything at platform level
app.use(express.static('public'));
app.use('/api', blobRoutes);

Step 4: Deploy and Verify

After deploying the changes:

Restart the App Service to apply the new configuration
Test the UI: Navigate to the root URL → should redirect to Entra ID login
Test the API: POST /api/blobs → should work without authentication (returns 201)
Verify auth headers: After login, check /.auth/me to see the authenticated user identity

Results

UI is protected: Unauthenticated users are redirected to Entra ID login

API routes are open: File uploads work without authentication

No custom code: Azure Entra ID authentication handles everything at the platform level

Token store enabled: Authenticated user identity available via /.auth/me

Key Takeaways

Use file-based configuration when Azure Entra ID authentication portal options are limited or unavailable
Let the platform handle authentication - don't implement custom middleware that competes with Azure Entra ID authentication
Use excludedPaths to selectively bypass authentication for specific routes (like APIs)
Use the correct issuer URL: login.microsoftonline.com/{tenant}/v2.0 for Entra ID v2.0
Reference sensitive values via app settings instead of hardcoding in JSON

Documentation References

Conclusion

File-based Azure Entra ID authentication configuration proved to be the most reliable solution for my use case. It provides fine-grained control over which routes require authentication while keeping the configuration declarative and version-controlled.

If you're facing similar challenges with Azure App Service authentication, I highly recommend exploring the file-based approach before diving into complex REST API patches or custom middleware solutions.

Have you encountered similar authentication challenges with Azure App Service? Share your experiences in the comments!

Managing Sensitive Information in Terraform and Azure

Mikael Krief — Wed, 29 Oct 2025 14:27:24 +0000

Managing sensitive information is one of the major challenges in adopting Infrastructure as Code (IaC) with Terraform. When we automate the deployment of Azure infrastructure, we inevitably handle critical data: passwords, API keys, certificates, connection strings, and other secrets that should never be exposed.

Terraform, as an Infrastructure as Code tool, offers a powerful declarative approach to managing Azure infrastructure. However, this approach introduces specific security risks related to the persistence and sharing of configurations. The Terraform state file (terraform.tfstate) contains the complete state of your infrastructure, including all sensitive values in plaintext. Similarly, storing Terraform code in version control systems like Git can expose secrets if best practices are not followed.

Main risks include:

Exposure in the state file: terraform.tfstate stores all resource attribute values, including passwords and keys
Leakage via version control: Hard-coded secrets in .tf files can be accidentally committed to Git
Logs and outputs: Sensitive values may appear in Terraform logs or plan/apply outputs
State sharing: Sharing the state file with the team exposes secrets to all members
Compliance and audit: Difficulty tracking access and use of sensitive information

Objective of This Article:

This comprehensive guide is intended for DevOps engineers and cloud architects who need to implement secure secrets management practices with Terraform and Azure. We will explore:

Existing security issues with the state file and Git
Native Terraform features for sensitive values
Last Terraform feature with ephemeral resources
Integration with Azure Key Vault for secure secrets management
Best practices and recommended patterns

Whether you're starting with Terraform or looking to improve your existing security practices, this article will provide you with the knowledge and practical examples needed to protect your sensitive information.

Existing Security Problems

The Terraform State File (terraform.tfstate)

The Terraform state file is at the heart of Terraform's operation, but it also represents the greatest security risk.

State File Structure and Content

The terraform.tfstate file is a JSON file that contains:

{
  "version": 4,
  "terraform_version": "1.9.0",
  "serial": 42,
  "lineage": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "outputs": {
    "database_password": {
      "value": "SuperSecretPassword123!",
      "type": "string",
      "sensitive": true
    }
  },
  "resources": [
    {
      "mode": "managed",
      "type": "azurerm_sql_server",
      "name": "example",
      "provider": "provider[\"registry.terraform.io/hashicorp/azurerm\"]",
      "instances": [
        {
          "attributes": {
            "id": "/subscriptions/.../servers/example-sql",
            "name": "example-sql",
            "administrator_login": "sqladmin",
            "administrator_login_password": "P@ssw0rd123!ComplexPassword",
            "version": "12.0"
          }
        }
      ]
    }
  ]
}

Security Issues:

Plaintext Storage: All resource attributes, including passwords, are stored in plain text in the state file
No Native Encryption: By default, Terraform does not encrypt the state file locally
Git History: If the state file is committed to Git, secrets remain in the history even after deletion
Backups: State file backups (.tfstate.backup) also contain secrets

Impact on Remote Backends

Even with a remote backend like Azure Storage, risks persist:

terraform {
  backend "azurerm" {
    resource_group_name  = "terraform-state-rg"
    storage_account_name = "tfstatexxxxxx"
    container_name       = "tfstate"
    key                  = "prod.terraform.tfstate"
  }
}

Risks with Remote Backends:

Storage Access: Anyone with access to the storage account can read the state file and its secrets
Azure Logs: Read/write operations may be logged with sensitive metadata
Automatic Backups: Backup systems may create unencrypted copies
Replication: Geographic replications duplicate secrets in multiple regions

Reference: Terraform State Management

Secrets in Source Code and Git

The Hard-Coding Problem

Hard-coding secrets directly in Terraform files is a dangerous but unfortunately common practice:

Problematic Example:

resource "azurerm_sql_server" "example" {
  name                         = "example-sqlserver"
  resource_group_name          = azurerm_resource_group.example.name
  location                     = azurerm_resource_group.example.location
  version                      = "12.0"
  administrator_login          = "sqladmin"
  administrator_login_password = "ThisIsATerriblePassword123!"  # DANGER!
}

resource "azurerm_storage_account" "example" {
  name                     = "examplestorage"
  resource_group_name      = azurerm_resource_group.example.name
  location                 = azurerm_resource_group.example.location
  account_tier             = "Standard"
  account_replication_type = "LRS"

  # Hard-coded API key - DANGER!
  tags = {
    api_key = "ak_live_1234567890abcdefghijklmnop"
  }
}

Consequences:

Permanent Exposure: Once committed to Git, the secret remains in history
Uncontrolled Access: All developers with repo access can see the secrets
Rotation Difficulties: Changing a secret requires modifying code and redeploying
Impossible Audit: Cannot trace who accessed the secrets

Risks with Git and Version Control Systems

# The secret is now in Git history
git add main.tf
git commit -m "Add SQL Server configuration"
git push origin main

# Even after deletion, the secret remains accessible
git log --all --full-history -- main.tf
git show <commit-hash>:main.tf

Exposure Vectors:

Public Repositories: Secrets exposed to the internet if the repo is public
Forks and Clones: Repository copies contain the secrets
Pull Requests: Secrets may be visible in PR diffs
CI/CD Logs: Pipelines may display secrets in logs

Secret Detection in Git

Use tools to scan Git history:

# Install gitleaks
brew install gitleaks

# Scan the repository
gitleaks detect --source . --verbose

# Scan complete history
gitleaks detect --source . --log-opts="--all"

Example Result:

Finding:     administrator_login_password = "ThisIsATerriblePassword123!"
Secret:      ThisIsATerriblePassword123!
RuleID:      generic-api-key
Entropy:     3.891820
File:        main.tf
Line:        15
Commit:      a1b2c3d4e5f6
Author:      developer@company.com
Date:        2024-10-29

Reference: Gitleaks Documentation

Issues with Outputs and Logs

Exposure in Terraform Outputs

Terraform outputs can also expose secrets:

output "database_connection_string" {
  value = "Server=${azurerm_sql_server.example.fully_qualified_domain_name};Database=mydb;User Id=${azurerm_sql_server.example.administrator_login};******;"
}

Problem: This output displays the password in plaintext when running terraform output.

Plan and Apply Logs

Terraform commands can expose sensitive values:

# The plan displays values in plaintext
terraform plan

# Example of problematic output:
# + administrator_login_password = "ThisIsATerriblePassword123!"

Impact:

CI/CD Logs: Pipelines store logs with secrets
Terminal History: Commands with secrets remain in bash history
System Logs: Logging systems may capture outputs

Managing Sensitive Values in Terraform

Terraform provides several native mechanisms to improve the management of sensitive information.

The `sensitive` Attribute

For Variables

Mark variables as sensitive to mask their value:

variable "database_password" {
  description = "Password for the SQL Server administrator"
  type        = string
  sensitive   = true
}

variable "api_key" {
  description = "API key for external service"
  type        = string
  sensitive   = true
}

Behavior:

# During plan, the value is masked
terraform plan

# Output:
# + administrator_login_password = (sensitive value)

Explanation: The sensitive = true attribute tells Terraform to mask the value in all outputs, logs, and plans. However, the value is still stored in plaintext in the state file.

For Outputs

Protect outputs containing sensitive information:

output "database_password" {
  description = "The password for the database administrator"
  value       = azurerm_sql_server.example.administrator_login_password
  sensitive   = true
}

output "connection_string" {
  description = "Full database connection string"
  value       = "Server=${azurerm_sql_server.example.fully_qualified_domain_name};..."
  sensitive   = true
}

Usage:

# Sensitive outputs don't display automatically
terraform output

# To see a specific sensitive value
terraform output -raw database_password

Explanation: Outputs marked as sensitive require explicit action to be displayed, reducing the risk of accidental exposure.

Reference: Sensitive Variables in Terraform

Environment Variables

Use environment variables to pass secrets:

# Define environment variables
export TF_VAR_database_password="SecurePassword123!"
export TF_VAR_api_key="sk_live_abcdefghijklmnop"

# Terraform automatically uses these variables
terraform plan
terraform apply

Terraform Configuration:

variable "database_password" {
  type      = string
  sensitive = true
  # No default value to force use of environment variable
}

resource "azurerm_sql_server" "example" {
  name                         = "example-sqlserver"
  resource_group_name          = azurerm_resource_group.example.name
  location                     = azurerm_resource_group.example.location
  version                      = "12.0"
  administrator_login          = "sqladmin"
  administrator_login_password = var.database_password
}

Advantages:

Secrets not stored in files
Facilitates CI/CD integration
Compatible with secret managers

Limitations:

Secrets remain in the state file
Accessible via shell history
No automatic rotation

Separate Variable Files

Use separate .tfvars files for secrets:

# variables.tf
variable "database_password" {
  type      = string
  sensitive = true
}

variable "admin_username" {
  type = string
}

# terraform.tfvars (NOT COMMITTED to Git)
admin_username      = "sqladmin"
database_password   = "SecurePassword123!"

# .gitignore
*.tfvars
!terraform.tfvars.example
terraform.tfstate*
.terraform/

Usage:

# Terraform automatically loads terraform.tfvars
terraform plan

# Or specify a specific file
terraform plan -var-file="production.tfvars"

Template for the Team:

# terraform.tfvars.example (committed to Git)
admin_username      = "sqladmin"
database_password   = "CHANGE_ME_TO_SECURE_PASSWORD"
api_key            = "CHANGE_ME_TO_YOUR_API_KEY"

Explanation: This approach separates secrets from source code. Developers copy the example file and fill in the real values locally.

Integration with Azure Key Vault (Traditional Approach)

Reading Secrets from Key Vault

Use the azurerm_key_vault_secret data source:

# Reference to existing Key Vault
data "azurerm_key_vault" "example" {
  name                = "mykeyvault"
  resource_group_name = "keyvault-rg"
}

# Read a secret
data "azurerm_key_vault_secret" "db_password" {
  name         = "database-admin-password"
  key_vault_id = data.azurerm_key_vault.example.id
}

# Use the secret
resource "azurerm_sql_server" "example" {
  name                         = "example-sqlserver"
  resource_group_name          = azurerm_resource_group.example.name
  location                     = azurerm_resource_group.example.location
  version                      = "12.0"
  administrator_login          = "sqladmin"
  administrator_login_password = data.azurerm_key_vault_secret.db_password.value
}

Advantages:

Centralization of secrets in Azure Key Vault
Secret rotation without modifying Terraform code
Audit and traceability via Azure Monitor
Access control with Azure RBAC

Critical Limitations:

The secret is still in the state file: The data source reads the secret and stores it in terraform.tfstate
No runtime protection: The secret is exposed in memory during execution
Logs and Outputs: Risk of exposure if misconfigured

Reference: Azure Key Vault with Terraform

Last Terraform feature Innovations: Ephemeral Resources

Introduction to Ephemeral Resources

Terraform 1.10+ introduces the revolutionary concept of ephemeral resources. These resources are specifically designed to handle sensitive data that should only exist at runtime and should never be stored in the state file.

Main Characteristics:

No Persistence: Values are never written to terraform.tfstate
Limited Lifetime: Exist only during Terraform execution
Read-Only: Intended for consumption, not for creating permanent resources
Security by Design: Designed to minimize secret exposure

Concept and Operation

Ephemeral Resource Syntax

ephemeral "azurerm_key_vault_secret" "db_password" {
  name         = "database-admin-password"
  key_vault_id = data.azurerm_key_vault.example.id
}

Difference from Classic Data Sources:

Aspect	Classic Data Source	Ephemeral Resource
State Storage	✅ Yes	❌ No
Persistence	Permanent	Temporary
Availability	Always	During execution only
Security	Medium	High
Use Case	Infrastructure data	Secrets and credentials

Explanation: Ephemeral resources are read at runtime and their value is immediately used without ever being stored. This eliminates the major risk of exposure via the state file.

Lifecycle of Ephemeral Resources

┌─────────────────┐
│ terraform plan  │
│                 │
│ 1. Read secret  │
│    from Key     │
│    Vault        │
│                 │
│ 2. Use in       │
│    memory       │
│                 │
│ 3. Validate     │
│    plan         │
│                 │
│ 4. ❌ NO        │
│    storage      │
└─────────────────┘
        ↓
┌─────────────────┐
│ terraform apply │
│                 │
│ 1. New read     │
│                 │
│ 2. Apply        │
│    changes      │
│                 │
│ 3. ❌ NO        │
│    storage      │
└─────────────────┘

Limitations and Constraints

Ephemeral resources have intentional restrictions to ensure security:

# ❌ FORBIDDEN: Use ephemeral resource in output
output "password" {
  value = ephemeral.azurerm_key_vault_secret.db_password.value
  # ERROR: Ephemeral resources cannot be used in outputs
}

# ❌ FORBIDDEN: Store in local variable
locals {
  saved_password = ephemeral.azurerm_key_vault_secret.db_password.value
  # ERROR: Ephemeral values cannot be stored in locals
}

# ✅ ALLOWED: Direct use in a resource
resource "azurerm_sql_server" "example" {
  administrator_login_password = ephemeral.azurerm_key_vault_secret.db_password.value
}

Explanation: These restrictions ensure that ephemeral values cannot be accidentally persisted or exposed.

Reference: Terraform Ephemeral Resources RFC

Practical Example with Azure Key Vault and Ephemeral Resources

Solution Architecture

Here's a complete architecture for securely managing secrets with Terraform and Azure:

┌─────────────────────────────────────────────────────┐
│                  Azure Subscription                  │
│                                                      │
│  ┌────────────────┐         ┌──────────────────┐   │
│  │   Key Vault    │         │  SQL Server      │   │
│  │                │         │                  │   │
│  │  - Secrets     │────────▶│  Uses ephemeral  │   │
│  │  - Access      │         │  secret for      │   │
│  │    Policies    │         │  admin password  │   │
│  │  - RBAC        │         │                  │   │
│  └────────────────┘         └──────────────────┘   │
│         ▲                                           │
│         │                                           │
│         │ Ephemeral Read (not stored)              │
│         │                                           │
│  ┌──────┴──────────────────────────────────────┐   │
│  │         Terraform Execution                  │   │
│  │                                              │   │
│  │  - Reads secrets at runtime                 │   │
│  │  - Never stores in tfstate                  │   │
│  │  - Applies configuration                    │   │
│  └─────────────────────────────────────────────┘   │
│                                                      │
└─────────────────────────────────────────────────────┘

Infrastructure Setup

Step 1: Create Key Vault and Secrets

# Resource Group
resource "azurerm_resource_group" "example" {
  name     = "secure-terraform-rg"
  location = "West Europe"

  tags = {
    Environment = "Production"
    ManagedBy   = "Terraform"
    Purpose     = "Secure Secrets Management"
  }
}

# Current Azure AD Configuration
data "azurerm_client_config" "current" {}

# Key Vault
resource "azurerm_key_vault" "example" {
  name                       = "secure-kv-${random_integer.suffix.result}"
  location                   = azurerm_resource_group.example.location
  resource_group_name        = azurerm_resource_group.example.name
  tenant_id                  = data.azurerm_client_config.current.tenant_id
  sku_name                   = "standard"

  # Enhanced security
  soft_delete_retention_days = 90
  purge_protection_enabled   = true

  # Disable public access if needed
  public_network_access_enabled = true

  # Network ACLs to restrict access
  network_acls {
    default_action = "Deny"
    bypass         = "AzureServices"
    ip_rules       = ["203.0.113.0/24"]  # Your public IP
  }

  tags = {
    Environment = "Production"
    ManagedBy   = "Terraform"
  }
}

# Random suffix for unique name
resource "random_integer" "suffix" {
  min = 10000
  max = 99999
}

# Access Policy for Terraform (Service Principal or Managed Identity)
resource "azurerm_key_vault_access_policy" "terraform" {
  key_vault_id = azurerm_key_vault.example.id
  tenant_id    = data.azurerm_client_config.current.tenant_id
  object_id    = data.azurerm_client_config.current.object_id

  secret_permissions = [
    "Get",
    "List",
    "Set",
    "Delete",
    "Recover",
    "Backup",
    "Restore"
  ]
}

# Create secrets (with recommended rotation)
resource "azurerm_key_vault_secret" "db_admin_password" {
  name         = "sql-admin-password"
  value        = random_password.db_admin.result
  key_vault_id = azurerm_key_vault.example.id

  content_type = "password"

  tags = {
    Purpose = "SQL Server Admin Password"
  }

  depends_on = [
    azurerm_key_vault_access_policy.terraform
  ]
}

# Generate a secure password
resource "random_password" "db_admin" {
  length           = 32
  special          = true
  override_special = "!#$%&*()-_=+[]{}<>:?"
  min_lower        = 1
  min_upper        = 1
  min_numeric      = 1
  min_special      = 1
}

Explanation: This configuration creates a secure Key Vault with soft delete and purge protection enabled. Network ACLs restrict Key Vault access. The password is automatically generated with high complexity.

Step 2: Use Ephemeral Resources

# Terraform configuration with version 1.10+
terraform {
  required_version = ">= 1.10"

  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 4.39"
    }
  }

  backend "azurerm" {
    resource_group_name  = "terraform-state-rg"
    storage_account_name = "tfstatexxxxxx"
    container_name       = "tfstate"
    key                  = "secure-prod.terraform.tfstate"
    use_azuread_auth     = true
  }
}

provider "azurerm" {
  features {
    key_vault {
      purge_soft_delete_on_destroy    = false
      recover_soft_deleted_key_vaults = true
    }
  }
}

# Key Vault reference
data "azurerm_key_vault" "example" {
  name                = "secure-kv-12345"
  resource_group_name = "secure-terraform-rg"
}

# ✨ NEW: Ephemeral Resource for password
ephemeral "azurerm_key_vault_secret" "db_admin_password" {
  name         = "sql-admin-password"
  key_vault_id = data.azurerm_key_vault.example.id
}

# SQL Server using ephemeral secret
resource "azurerm_mssql_server" "example" {
  name                         = "secure-sqlserver-${random_integer.suffix.result}"
  resource_group_name          = azurerm_resource_group.example.name
  location                     = azurerm_resource_group.example.location
  version                      = "12.0"

  administrator_login          = "sqladmin"
  # ✨ Direct use of ephemeral secret
  administrator_login_password = ephemeral.azurerm_key_vault_secret.db_admin_password.value

  # Enhanced security
  minimum_tls_version               = "1.2"
  public_network_access_enabled     = false

  azuread_administrator {
    login_username = "AzureAD Admin"
    object_id      = data.azurerm_client_config.current.object_id
  }

  tags = {
    Environment = "Production"
    ManagedBy   = "Terraform"
  }
}

# SQL Database
resource "azurerm_mssql_database" "example" {
  name      = "exampledb"
  server_id = azurerm_mssql_server.example.id

  sku_name = "S0"

  tags = {
    Environment = "Production"
    ManagedBy   = "Terraform"
  }
}

Explanation: The ephemeral resource ephemeral.azurerm_key_vault_secret.db_admin_password reads the secret from Key Vault at runtime. The value is used to configure the SQL Server but is never stored in the state file.

Step 3: Secure Network Configuration

# Private Endpoint for Key Vault
resource "azurerm_private_endpoint" "keyvault" {
  name                = "keyvault-pe"
  location            = azurerm_resource_group.example.location
  resource_group_name = azurerm_resource_group.example.name
  subnet_id           = azurerm_subnet.private_endpoints.id

  private_service_connection {
    name                           = "keyvault-privateserviceconnection"
    private_connection_resource_id = azurerm_key_vault.example.id
    is_manual_connection           = false
    subresource_names              = ["vault"]
  }

  private_dns_zone_group {
    name                 = "keyvault-dns-zone-group"
    private_dns_zone_ids = [azurerm_private_dns_zone.keyvault.id]
  }
}

# Private DNS Zone for Key Vault
resource "azurerm_private_dns_zone" "keyvault" {
  name                = "privatelink.vaultcore.azure.net"
  resource_group_name = azurerm_resource_group.example.name
}

# Private Endpoint for SQL Server
resource "azurerm_private_endpoint" "sqlserver" {
  name                = "sqlserver-pe"
  location            = azurerm_resource_group.example.location
  resource_group_name = azurerm_resource_group.example.name
  subnet_id           = azurerm_subnet.private_endpoints.id

  private_service_connection {
    name                           = "sqlserver-privateserviceconnection"
    private_connection_resource_id = azurerm_mssql_server.example.id
    is_manual_connection           = false
    subresource_names              = ["sqlServer"]
  }

  private_dns_zone_group {
    name                 = "sqlserver-dns-zone-group"
    private_dns_zone_ids = [azurerm_private_dns_zone.sqlserver.id]
  }
}

# Private DNS Zone for SQL Server
resource "azurerm_private_dns_zone" "sqlserver" {
  name                = "privatelink.database.windows.net"
  resource_group_name = azurerm_resource_group.example.name
}

Explanation: Private Endpoints ensure that communication to Key Vault and SQL Server never traverses the public internet, adding a network security layer.

Reference: Azure Private Endpoints

Comparison: Before and After Ephemeral Resources

Traditional Approach (Data Source)

# ❌ Traditional approach - Security risks
data "azurerm_key_vault_secret" "db_password" {
  name         = "sql-admin-password"
  key_vault_id = data.azurerm_key_vault.example.id
}

resource "azurerm_mssql_server" "example" {
  administrator_login_password = data.azurerm_key_vault_secret.db_password.value
  # ...
}

Resulting State File:

{
  "resources": [
    {
      "type": "azurerm_key_vault_secret",
      "name": "db_password",
      "instances": [
        {
          "attributes": {
            "value": "SuperSecretPassword123!",  // ❌ SECRET EXPOSED
            "name": "sql-admin-password"
          }
        }
      ]
    }
  ]
}

New Approach (Ephemeral Resource)

# ✅ New approach - Secure
ephemeral "azurerm_key_vault_secret" "db_password" {
  name         = "sql-admin-password"
  key_vault_id = data.azurerm_key_vault.example.id
}

resource "azurerm_mssql_server" "example" {
  administrator_login_password = ephemeral.azurerm_key_vault_secret.db_password.value
  # ...
}

Resulting State File:

{
  "resources": [
    {
      "type": "azurerm_mssql_server",
      "name": "example",
      "instances": [
        {
          "attributes": {
            "name": "example-sqlserver",
            "administrator_login": "sqladmin",
            // ✅ NO administrator_login_password in state
          }
        }
      ]
    }
  ]
}

Explanation: With ephemeral resources, the password never appears in the state file, eliminating the most critical exposure risk.

Advanced Management: Automatic Secret Rotation

# Automatic password rotation with time_rotating
resource "time_rotating" "db_password_rotation" {
  rotation_days = 90  # Rotation every 90 days
}

resource "random_password" "db_admin" {
  length           = 32
  special          = true
  override_special = "!#$%&*()-_=+[]{}<>:?"

  keepers = {
    rotation_time = time_rotating.db_password_rotation.id
  }
}

resource "azurerm_key_vault_secret" "db_admin_password" {
  name         = "sql-admin-password"
  value        = random_password.db_admin.result
  key_vault_id = azurerm_key_vault.example.id

  lifecycle {
    create_before_destroy = true
  }
}

# Ephemeral resource always uses latest version
ephemeral "azurerm_key_vault_secret" "db_admin_password" {
  name         = "sql-admin-password"
  key_vault_id = data.azurerm_key_vault.example.id
}

Explanation: The time_rotating resource automatically triggers password regeneration every 90 days. The lifecycle.create_before_destroy ensures a new password is created before the old one is deleted, avoiding interruptions.

Reference: Time Provider

Best Practices and Recommendations

Securing the State File

Encryption at Rest

For Azure Storage Backend:

resource "azurerm_storage_account" "tfstate" {
  name                     = "tfstate${random_integer.suffix.result}"
  resource_group_name      = azurerm_resource_group.state.name
  location                 = azurerm_resource_group.state.location
  account_tier             = "Standard"
  account_replication_type = "GRS"

  # Encryption with customer-managed keys
  customer_managed_key {
    key_vault_key_id = azurerm_key_vault_key.tfstate.id
  }

  # Enhanced security
  min_tls_version              = "TLS1_2"
  allow_nested_items_to_be_public = false

  blob_properties {
    versioning_enabled = true

    delete_retention_policy {
      days = 90
    }
  }
}

Explanation: Using Customer-Managed Keys (CMK) to encrypt state storage adds an extra layer of protection.

Strict Access Control

# RBAC for state file access
az role assignment create \
  --role "Storage Blob Data Contributor" \
  --assignee <terraform-sp-id> \
  --scope "/subscriptions/<sub-id>/resourceGroups/terraform-state-rg/providers/Microsoft.Storage/storageAccounts/tfstate"

# Limit access to only necessary users
az role assignment create \
  --role "Storage Blob Data Reader" \
  --assignee <developer-group-id> \
  --scope "/subscriptions/<sub-id>/resourceGroups/terraform-state-rg"

Explanation: Apply the principle of least privilege. Only Terraform service accounts should have write access, while developers can have read-only access if necessary.

Secret Rotation Strategy

Secret Type	Rotation Frequency	Method
Admin Passwords	90 days	Automatic with `time_rotating`
External API Keys	180 days	Manual with notification
Certificates	365 days	Automatic via Key Vault
Access Tokens	30 days	Automatic with OAuth refresh

Implementing Rotation Alerts:

resource "azurerm_monitor_action_group" "secrets_rotation" {
  name                = "secrets-rotation-alerts"
  resource_group_name = azurerm_resource_group.example.name
  short_name          = "secretrot"

  email_receiver {
    name          = "security-team"
    email_address = "security@company.com"
  }
}

resource "azurerm_monitor_metric_alert" "key_vault_secret_expiry" {
  name                = "keyvault-secret-expiry"
  resource_group_name = azurerm_resource_group.example.name
  scopes              = [azurerm_key_vault.example.id]

  description = "Alert when secrets are about to expire"
  severity    = 2

  criteria {
    metric_namespace = "Microsoft.KeyVault/vaults"
    metric_name      = "ServiceApiLatency"
    aggregation      = "Average"
    operator         = "GreaterThan"
    threshold        = 1000
  }

  action {
    action_group_id = azurerm_monitor_action_group.secrets_rotation.id
  }
}

Security Checklist

Project Configuration

[ ] No hard-coded secrets in .tf files
[ ] All .tfvars files containing secrets are in .gitignore
[ ] Sensitive variables marked with sensitive = true
[ ] Sensitive outputs marked with sensitive = true
[ ] No sensitive terraform output in CI/CD scripts

State File

[ ] Remote backend configured (Azure Storage, Terraform Cloud, etc.)
[ ] Encryption at rest enabled on backend
[ ] Strict access control (RBAC) configured
[ ] Versioning enabled for recovery
[ ] Soft delete configured (90 days minimum)

Azure Key Vault

[ ] Ephemeral resources used to read secrets
[ ] Soft delete and purge protection enabled
[ ] Network ACLs or Private Endpoints configured
[ ] RBAC configured with least privilege principle
[ ] Monitoring and alerts configured
[ ] Automatic secret rotation implemented

CI/CD and Automation

[ ] Environment variables used for secrets
[ ] Integration with secret manager (GitHub Secrets, Azure DevOps Variables)
[ ] Terraform logs filtered to mask sensitive values
[ ] Service Principal or Managed Identity for authentication
[ ] No access keys in pipelines

Compliance and Audit

[ ] Key Vault access logs enabled
[ ] Integration with Azure Monitor
[ ] Alerts configured for suspicious access
[ ] Documentation of rotation procedures
[ ] Secret recovery tests

Anti-Patterns

❌ Anti-Patterns to Avoid

# ❌ BAD: Hard-coding secrets
resource "azurerm_sql_server" "bad" {
  administrator_login_password = "Password123!"
}

# ❌ BAD: Secrets in default variables
variable "api_key" {
  default = "sk_live_1234567890"
}

# ❌ BAD: Output secrets without sensitive
output "password" {
  value = azurerm_sql_server.example.administrator_login_password
}

# ❌ BAD: Using data source instead of ephemeral
data "azurerm_key_vault_secret" "bad" {
  name         = "secret"
  key_vault_id = data.azurerm_key_vault.example.id
}

# ❌ BAD: Secrets in tags
resource "azurerm_resource_group" "bad" {
  tags = {
    api_key = var.api_key
  }
}

✅ Best Practices

# ✅ GOOD: Sensitive variables without default value
variable "api_key" {
  type      = string
  sensitive = true
  # No default - must be provided via environment variable
}

# ✅ GOOD: Ephemeral resources for secrets
ephemeral "azurerm_key_vault_secret" "good" {
  name         = "api-key"
  key_vault_id = data.azurerm_key_vault.example.id
}

# ✅ GOOD: Protected sensitive outputs
output "connection_string" {
  value     = local.connection_string
  sensitive = true
}

# ✅ GOOD: Automatic secret generation
resource "random_password" "good" {
  length  = 32
  special = true
}

resource "azurerm_key_vault_secret" "good" {
  name         = "generated-password"
  value        = random_password.good.result
  key_vault_id = azurerm_key_vault.example.id
}

# ✅ GOOD: Using Managed Identity
resource "azurerm_linux_virtual_machine" "good" {
  identity {
    type = "SystemAssigned"
  }
}

Secure CI/CD Configuration

GitHub Actions

name: 'Secure Terraform'

on:
  push:
    branches: [ main ]
  pull_request:

permissions:
  id-token: write
  contents: read

env:
  ARM_CLIENT_ID: ${{ secrets.AZURE_CLIENT_ID }}
  ARM_SUBSCRIPTION_ID: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
  ARM_TENANT_ID: ${{ secrets.AZURE_TENANT_ID }}
  ARM_USE_OIDC: true

jobs:
  terraform:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v4

    - name: Azure Login
      uses: azure/login@v2
      with:
        client-id: ${{ secrets.AZURE_CLIENT_ID }}
        tenant-id: ${{ secrets.AZURE_TENANT_ID }}
        subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

    - name: Setup Terraform
      uses: hashicorp/setup-terraform@v3
      with:
        terraform_version: 1.10.0

    - name: Terraform Init
      run: terraform init

    # Filter sensitive logs
    - name: Terraform Plan
      run: |
        terraform plan -no-color | grep -v "sensitive value"
      continue-on-error: false

    # Never log apply in production
    - name: Terraform Apply
      if: github.ref == 'refs/heads/main'
      run: terraform apply -auto-approve > /dev/null 2>&1

Explanation: This configuration uses OIDC for authentication without long-lived secrets. Logs are filtered and apply output is redirected to /dev/null to avoid exposing sensitive information.

Azure DevOps

trigger:
  branches:
    include:
    - main

pool:
  vmImage: 'ubuntu-latest'

variables:
- group: terraform-secrets  # Variable group with secrets

stages:
- stage: Plan
  jobs:
  - job: TerraformPlan
    steps:
    - task: AzureCLI@2
      inputs:
        azureSubscription: 'Azure-Service-Connection'
        scriptType: 'bash'
        scriptLocation: 'inlineScript'
        inlineScript: |
          terraform init
          terraform plan -no-color | grep -v "sensitive"

- stage: Apply
  dependsOn: Plan
  condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))
  jobs:
  - deployment: TerraformApply
    environment: 'production'
    strategy:
      runOnce:
        deploy:
          steps:
          - task: AzureCLI@2
            inputs:
              azureSubscription: 'Azure-Service-Connection'
              scriptType: 'bash'
              scriptLocation: 'inlineScript'
              inlineScript: |
                terraform init
                terraform apply -auto-approve 2>&1 | grep -v "password"

Reference: GitHub Actions Security

Conclusion

Secure management of sensitive information is a fundamental pillar of any Infrastructure as Code strategy with Terraform and Azure. Throughout this article, we've explored the challenges, existing solutions, and major innovations that transform our approach to security.

Key Takeaways

1. Understanding the Risks:

Terraform state files and Git source code represent the two main vectors for secret exposure. Without appropriate precautions:

Secrets are stored in plaintext in terraform.tfstate
Git history preserves secrets indefinitely
Logs and outputs can expose sensitive information
Team sharing multiplies uncontrolled access points

2. Adopt Native Features:

Terraform provides basic but essential mechanisms:

The sensitive attribute to mask values in outputs and logs
Environment variables to avoid hard-coding
Separate uncommitted .tfvars files
Integration with secure remote backends

3. Leverage Ephemeral Resources:

The feature revolution with ephemeral resources is a game-changer:

Zero storage of secrets in the state file
On-the-fly reading from Azure Key Vault
Lifetime limited to Terraform execution
Security by design with intentional restrictions

4. Implement a Comprehensive Strategy:

A holistic approach combines:

Azure Key Vault as centralized source of truth
Ephemeral resources for access without persistence
Automatic secret rotation
Complete monitoring and alerting
Strict access controls with RBAC
Private Endpoints for network isolation

Reference Architecture

┌─────────────────────────────────────────────────────────┐
│              Terraform Security Strategy                 │
│                                                          │
│  Level 1: Source Code                                   │
│  ✓ No hard-coded secrets                                │
│  ✓ .tfvars in .gitignore                                │
│  ✓ Sensitive variables marked                           │
│                                                          │
│  Level 2: Execution                                     │
│  ✓ Ephemeral resources for Key Vault                   │
│  ✓ Environment variables in CI/CD                       │
│  ✓ Sensitive log filtering                              │
│                                                          │
│  Level 3: State                                         │
│  ✓ Encrypted remote backend (Azure Storage)            │
│  ✓ Strict RBAC                                          │
│  ✓ Versioning and soft delete                          │
│                                                          │
│  Level 4: Secrets Management                            │
│  ✓ Centralized Azure Key Vault                         │
│  ✓ Automatic rotation                                  │
│  ✓ Private Endpoints                                   │
│  ✓ Monitoring and audit                                │
│                                                          │
└─────────────────────────────────────────────────────────┘

Implementation Roadmap

Phase 1: Audit and Cleanup (1-2 weeks)

Scan Git history to detect exposed secrets
Identify all hard-coded secrets in code
Clean Git history with BFG Repo-Cleaner or git-filter-branch
Revoke and regenerate all compromised secrets

Phase 2: Foundation (2-4 weeks)

Deploy Azure Key Vault with secure configuration
Migrate to remote backend for state file
Implement RBAC and access controls
Configure Private Endpoints

Phase 3: Migration to Ephemeral Resources (4-6 weeks)

Update Terraform to version 1.10+
Identify all secret data sources
Convert to ephemeral resources
Test in development then staging environment

Phase 4: Automation and Governance (Ongoing)

Implement automatic secret rotation
Configure monitoring and alerts
Establish incident response procedures
Train team on new practices

Future Perspectives

The Terraform and Azure ecosystem continues to evolve:

Expected Improvements:

Native support for ephemeral resources in more providers
Deeper integration between Terraform Cloud and Azure Key Vault
Improved secret leak detection and prevention tools
Automated compliance standards (SOC2, ISO 27001, HIPAA)

Emerging Trends:

Growing adoption of secretless authentication (Workload Identity, OIDC)
Homomorphic encryption for computation on sensitive data
Zero Trust Architecture with continuous validation
Integrated FinOps and secret governance

Final Recommendations

For New Projects:

Start directly with Terraform 1.10+ and ephemeral resources
Design your architecture with security from the start
Automate secret rotation from day one
Document your security practices

For Existing Projects:

Audit your current infrastructure
Prioritize migration of production environments
Proceed in stages to minimize disruptions
Train your team on new practices

For Teams:

Establish clear secret management policies
Automate security checks in CI/CD pipelines
Share knowledge and experiences
Stay updated with ecosystem evolution

Security is not a destination but a continuous journey. By adopting ephemeral resources and the best practices presented in this article, you build a more secure, compliant, and resilient Terraform infrastructure.

Remember: The best-protected secrets are those that never exist outside the moment they are used.

References

Official Terraform Documentation:

Azure Documentation:

Security and Compliance:

Tools and Utilities:

CI/CD and Automation:

Terraform Providers:

Articles and Blogs:

Transform Your DevOps Workflow with MCP Azure DevOps Integration

Mikael Krief — Thu, 11 Sep 2025 07:36:39 +0000

Azure DevOps has long been the backbone of enterprise development workflows, managing everything from work items and repositories to builds and deployments. Now, with the introduction of the Model Context Protocol (MCP) Azure DevOps Server, AI assistants can seamlessly integrate with your DevOps processes, bringing intelligent automation and contextual assistance directly to your development environment.

This comprehensive guide explores how to leverage the MCP Azure DevOps integration to supercharge your development workflows with real-world use cases and practical implementations.

What is MCP Azure DevOps?

The Azure DevOps Model Context Protocol (MCP) Server provides your AI assistant with secure access to work items, pull requests, builds, test plans, and documentation from your Azure DevOps organization. Unlike cloud-based solutions that require sending your data externally, the Azure DevOps MCP Server runs locally, ensuring your sensitive project data never leaves your infrastructure.

The Azure DevOps MCP Server is built from tools that are concise, simple, focused, and easy to use—each designed for a specific scenario. The goal is to provide a thin abstraction layer over the REST APIs, making data access straightforward and letting the language model handle complex reasoning.

Key Features and Capabilities

The MCP Azure DevOps integration provides comprehensive access to:

Work Item Management

Query, create, and update work items across projects
Manage backlog items, user stories, bugs, and tasks
Link related work items and establish dependencies
Bulk operations for efficient project management

Repository Operations

Access source code and repository structure
Review and manage pull requests
Analyze code changes and commit history
Branch management and merge operations

Build and Release Management

Monitor build pipeline status and results
Trigger builds and deployments
Analyze build failures and test results
Track release progress across environments

Project Administration

Team and project management
Sprint planning and backlog organization
Test plan creation and execution
Wiki and documentation access

Setup and Configuration

Prerequisites

Before getting started, ensure you have:

An Azure DevOps organization with appropriate permissions
A Personal Access Token (PAT) with necessary scopes
An MCP-compatible AI assistant (Claude, GitHub Copilot, etc.)

Installation Steps

Several community-maintained servers are available with additional features and customization options.

Integration with Development Tools

For GitHub Copilot in VS Code:
Enable a local MCP Server for Azure DevOps to bring contextual information from Azure DevOps into VS Code using GitHub Copilot by adding this configuration to your mcp.json:

{
  "servers": {
    "azure-devops": {
      "command": "node",
      "args": ["path/to/azure-devops-mcp/dist/index.js"],
      "env": {
        "AzureDevOps__OrganizationUrl": "https://dev.azure.com/your-org",
        "AzureDevOps__PersonalAccessToken": "your-pat"
      }
    }
  }
}

For Claude Desktop:
Add the server configuration to your Claude Desktop settings:

{
  "mcpServers": {
    "azure-devops": {
      "command": "azure-devops-mcp-server",
      "env": {
        "AZURE_DEVOPS_ORG_URL": "https://dev.azure.com/your-organization",
        "AZURE_DEVOPS_PAT": "your-personal-access-token"
      }
    }
  }
}

Read the installation documentation here

Detailed Use Cases

1. Intelligent Work Item Management and Planning

Scenario: You're a product manager preparing for the next sprint. You need to analyze the current backlog, create new user stories based on customer feedback, and organize work items by priority and team capacity.

How MCP Azure DevOps helps:
The AI assistant can analyze your backlog, understand project context, and help create well-structured work items with proper linking and organization.

Detailed workflow:

"Analyze our current sprint backlog for Project Alpha. Create 5 new user stories for the mobile checkout improvement based on the customer feedback in work item #1234. Organize them by priority and estimate story points."

The assistant will:

Backlog Analysis:
- Review current sprint work items and their status
- Analyze team velocity and capacity
- Identify blockers and dependencies
- Assess progress toward sprint goals
Context-Aware Story Creation:
- Extract requirements from customer feedback work item
- Generate user stories with proper acceptance criteria
- Apply consistent formatting and templates
- Add appropriate tags and area paths
Intelligent Organization:
- Prioritize based on business value and dependencies
- Estimate story points using historical data
- Assign to appropriate team members based on expertise
- Create parent-child relationships where needed

Sample Generated Work Items:

Epic: Mobile Checkout Improvement (Parent)

Title: Enhance Mobile Checkout Experience
Description: Improve the mobile checkout flow to reduce cart abandonment and increase conversion rates based on customer feedback analysis.

Acceptance Criteria:
- Reduce checkout steps from 5 to 3
- Implement guest checkout option
- Optimize for mobile screen sizes
- Integrate with popular payment methods

Story Points: 21
Priority: High
Assigned To: Mobile Team

User Story 1: Guest Checkout Implementation

Title: As a customer, I want to checkout without creating an account
Description: Enable guest checkout functionality to reduce friction for first-time customers

Acceptance Criteria:
- Guest users can complete purchase without registration
- Optional account creation after purchase
- Email receipt sent to guest customers
- Guest order tracking capability

Story Points: 8
Priority: High
Parent: Mobile Checkout Improvement Epic
Tags: mobile, checkout, guest-experience

Advanced Features:

Dependency Mapping: Automatically identify and link related work items
Template Application: Apply team-specific work item templates
Bulk Operations: Create multiple related work items efficiently
Historical Analysis: Use past sprint data to improve estimations

2. Advanced Pull Request Analysis and Code Review

Scenario: Your team has implemented a new microservice for payment processing. The pull request contains 47 files with 1,200+ lines of changes across multiple components. You need comprehensive analysis for security, performance, and architectural compliance.

How MCP Azure DevOps helps:
The assistant can perform deep code analysis, understand architectural patterns, and provide comprehensive review feedback while maintaining context of your existing codebase.

Detailed workflow:

"Review pull request #892 for the payment service implementation. Focus on security vulnerabilities, performance implications, and compliance with our microservice architecture patterns. Also check if proper logging and monitoring are implemented."

The assistant will:

Comprehensive Code Analysis:
- Review all changed files for security patterns
- Analyze API endpoint implementations
- Check database query efficiency
- Validate error handling strategies
Architecture Compliance Review:
- Ensure adherence to microservice patterns
- Validate service boundaries and dependencies
- Check configuration management
- Review containerization setup
Security Assessment:
- Identify potential SQL injection vulnerabilities
- Review authentication and authorization logic
- Check for sensitive data exposure
- Validate input sanitization

Sample Analysis Output:

🔒 Security Analysis:

HIGH PRIORITY ISSUES:
⚠️  PaymentController.cs (Line 67): User input directly used in SQL query
    Recommendation: Use parameterized queries with Entity Framework

⚠️  PaymentService.cs (Line 134): API key exposed in log statements  
    Recommendation: Implement structured logging with data redaction

MEDIUM PRIORITY:
⚡ PaymentValidator.cs (Line 23): Missing rate limiting for validation endpoints
    Recommendation: Implement rate limiting middleware

🚀 Performance Review:

OPTIMIZATION OPPORTUNITIES:
⚡ PaymentRepository.cs (Line 89): N+1 query pattern detected
   Current: Individual queries for each payment method
   Suggestion: Use Include() for eager loading related data

⚡ PaymentProcessor.cs (Line 156): Synchronous external API calls
   Recommendation: Implement async/await pattern for external payment APIs

⚡ CacheService.cs (Line 45): Cache keys not following naming convention
   Suggestion: Use consistent cache key patterns: "payment:{id}:{version}"

🏗️ Architecture Compliance:

✅ COMPLIANT AREAS:
- Service registration follows dependency injection patterns
- Configuration properly externalized to appsettings
- Health checks implemented correctly
- OpenAPI documentation generated

⚠️  AREAS FOR IMPROVEMENT:
- Missing distributed tracing correlation IDs
- Circuit breaker not implemented for external payment APIs
- Metrics collection incomplete (missing business metrics)

Advanced Analysis Features:

Dependency Impact: Analyze how changes affect other services
Performance Benchmarking: Compare against existing service patterns
Test Coverage: Validate unit and integration test completeness
Documentation Review: Ensure API documentation matches implementation

3. Automated Sprint Planning and Capacity Management

Scenario: You're leading a development team of 12 people across 3 time zones. Sprint planning needs to consider individual capacity, skill sets, dependencies between work items, and upcoming holidays. You want to optimize sprint commitment and identify potential bottlenecks.

How MCP Azure DevOps helps:
The assistant can analyze team capacity, historical velocity, work item dependencies, and create optimized sprint plans that balance workload and minimize risks.

Detailed workflow:

"Plan our upcoming 2-week sprint for the Platform Team. Consider John's vacation (3 days), Sarah's focus on the security audit, and the dependency between the API redesign and mobile app updates. Optimize for team capacity and minimize blockers."

The assistant will:

Team Capacity Analysis:
- Calculate available hours per team member
- Account for planned time off and commitments
- Consider individual skill sets and expertise
- Factor in historical velocity data
Work Item Prioritization:
- Analyze backlog items by business value
- Identify critical path dependencies
- Group related work items for efficiency
- Balance different types of work (features, bugs, technical debt)
Risk Assessment:
- Identify potential blockers and dependencies
- Highlight work items requiring specific expertise
- Suggest contingency plans for high-risk items
- Recommend parallel work streams

Sample Sprint Plan Output:

📊 Sprint 23 Planning Summary

Sprint Duration: 2 weeks (March 15-28, 2025)
Team Capacity: 180 hours (adjusted for vacation and commitments)
Planned Commitment: 156 story points
Confidence Level: 85% (based on historical velocity)

👥 Team Capacity Breakdown:

Available Team Members (9/12):
✅ Alice (Frontend) - 40h available, velocity: 18 SP/sprint
✅ Bob (Backend) - 35h available (5h allocated to security review)
✅ Carol (DevOps) - 40h available, velocity: 15 SP/sprint
⚠️  David (Full-stack) - 25h available (vacation Mar 18-20)
❌ John (Backend Lead) - Unavailable (vacation)
✅ Sarah (Security) - 20h available (focused on audit)

🎯 Recommended Sprint Commitment:

High Priority (Must Have):

1. User Authentication Redesign (#1567) - 13 SP
   Assigned: Bob (Backend) + Alice (Frontend)
   Dependencies: None
   Risk: Low

2. API Rate Limiting Implementation (#1589) - 8 SP  
   Assigned: Carol (DevOps)
   Dependencies: Authentication redesign
   Risk: Medium (dependency on #1567)

3. Mobile App API Integration (#1601) - 21 SP
   Assigned: David (25h) + Alice (Frontend support)
   Dependencies: API redesign completion
   Risk: High (David's reduced capacity)

Medium Priority (Should Have):

4. Database Performance Optimization (#1623) - 13 SP
   Assigned: Bob (remaining capacity)
   Dependencies: None
   Risk: Low

5. Security Audit Remediation (#1645) - 8 SP
   Assigned: Sarah (Security) + team support
   Dependencies: Audit completion
   Risk: Medium

📋 Sprint Execution Strategy:

Week 1 Focus:

Start authentication redesign immediately (Bob + Alice)
Begin mobile app foundation work (David)
Initiate database optimization (Bob, parallel work)

Week 2 Focus:

Complete API integrations (dependencies resolved)
Security remediation implementation
Testing and deployment preparation

⚠️ Risk Mitigation:

IDENTIFIED RISKS:
1. David's reduced capacity may impact mobile integration
   Mitigation: Alice provides additional frontend support

2. API redesign dependency chain
   Mitigation: Implement in phases, start mobile work with current APIs

3. Sarah's security focus limits development capacity  
   Mitigation: Schedule security work during team's testing phase

📈 Success Metrics:

Sprint completion rate: Target 90%+
Carry-over work: Maximum 2 story points
Team satisfaction: Monitor through retrospective feedback
Code quality: Maintain test coverage above 80%

4. Comprehensive Build Pipeline Analysis and Optimization

Scenario: Your organization has multiple projects with CI/CD pipelines that have become increasingly slow and unreliable. Build times have increased from 8 minutes to 25 minutes over the past 6 months, and the failure rate is 15%. You need to identify bottlenecks and optimize the entire build process.

How MCP Azure DevOps helps:
The assistant can analyze build history, identify failure patterns, suggest optimizations, and help implement more efficient pipeline strategies.

Detailed workflow:

"Analyze our build pipelines for the last 90 days. Identify the main causes of build failures and slowdowns. Suggest specific optimizations for our .NET microservices and React frontend pipelines."

The assistant will:

Build Performance Analysis:
- Analyze build duration trends over time
- Identify slowest pipeline stages
- Compare performance across different branches
- Assess resource utilization patterns
Failure Pattern Investigation:
- Categorize build failures by type and frequency
- Identify flaky tests and infrastructure issues
- Analyze failure correlation with code changes
- Track MTTR (Mean Time To Recovery) metrics
Optimization Recommendations:
- Suggest parallelization opportunities
- Recommend caching strategies
- Identify unnecessary pipeline steps
- Propose infrastructure improvements

Sample Analysis Report:

📊 Build Pipeline Health Report (90-day analysis)

Performance Metrics:

Total Builds Analyzed: 2,847 builds across 15 pipelines
Average Build Time: 22.3 minutes (↑ 180% from baseline)
Success Rate: 85.2% (↓ 12% from target)
Most Problematic Pipeline: payment-service-ci (31% failure rate)
Fastest Pipeline: notification-service (4.2 min avg)

🐛 Failure Analysis:

TOP FAILURE CATEGORIES:
1. Test Failures (45% of failures)
   - Flaky integration tests: 67 instances
   - Database connection timeouts: 34 instances
   - Environment setup issues: 23 instances

2. Build Compilation Errors (25% of failures)  
   - Package dependency conflicts: 45 instances
   - Missing environment variables: 18 instances
   - Code quality gate failures: 12 instances

3. Infrastructure Issues (20% of failures)
   - Agent availability timeouts: 28 instances
   - Network connectivity problems: 15 instances
   - Disk space limitations: 8 instances

4. Deployment Failures (10% of failures)
   - Configuration mismatches: 12 instances
   - Resource provisioning errors: 6 instances

⚡ Performance Bottlenecks:

Slowest Pipeline Stages:

1. Integration Tests (avg: 8.4 minutes)
   Issues: Sequential test execution, database resets
   Optimization: Parallel test execution, test containers

2. Package Restoration (avg: 4.2 minutes)
   Issues: Package cache misses, large dependencies  
   Optimization: Docker layer caching, package feed optimization

3. Code Quality Analysis (avg: 3.8 minutes)
   Issues: Full codebase scan on every build
   Optimization: Incremental analysis, result caching

4. Docker Image Building (avg: 3.1 minutes)
   Issues: No layer reuse, large base images
   Optimization: Multi-stage builds, base image optimization

🎯 Specific Optimization Recommendations:

Immediate Actions (Impact: High, Effort: Low):

# 1. Enable Parallel Test Execution
- task: DotNetCoreCLI@2
  displayName: 'Run Tests'
  inputs:
    command: 'test'
    projects: '**/*Tests.csproj'
    arguments: '--configuration Release --parallel --collect:"XPlat Code Coverage"'

# 2. Implement Package Caching  
- task: Cache@2
  inputs:
    key: 'nuget | "$(Agent.OS)" | packages.lock.json'
    restoreKeys: 'nuget | "$(Agent.OS)"'
    path: '$(Pipeline.Workspace)/.nuget/packages'

Medium-Term Improvements (Impact: High, Effort: Medium):

# 3. Docker Layer Optimization
FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS base
# Copy only package files first for better caching
COPY ["*.csproj", "./"]
RUN dotnet restore
# Copy source code after package restore
COPY . .
RUN dotnet publish -c Release -o out

# 4. Conditional Pipeline Execution
trigger:
  branches:
    include: [main, develop]
  paths:
    include: [src/PaymentService/*]
    exclude: [docs/*, README.md]

Strategic Changes (Impact: Very High, Effort: High):

5. Infrastructure Scaling:
   - Implement self-hosted agent pools (30% faster)
   - Use SSD storage for build agents (15% improvement)
   - Implement geographic agent distribution

6. Testing Strategy Overhaul:
   - Separate unit tests (fast feedback: <2 min)
   - Integration tests in parallel stages (reduced to 4 min)
   - Contract testing to reduce end-to-end test dependency

7. Build Optimization:
   - Implement incremental builds based on code changes
   - Use build matrices for multi-target scenarios
   - Optimize Docker images (reduce size by 60%)

📈 Expected Performance Improvements:

OPTIMIZATION IMPACT PROJECTIONS:
- Parallel testing: -40% test execution time
- Package caching: -60% restore time  
- Docker optimization: -45% image build time
- Infrastructure scaling: -25% overall build time

TOTAL EXPECTED IMPROVEMENT:
Current: 22.3 minutes average
Projected: 8.7 minutes average (-61% improvement)
ROI: ~$50,000/year in developer productivity

5. Intelligent Test Management and Quality Assurance

Scenario: Your team manages a complex e-commerce platform with 1,500+ automated tests across unit, integration, and end-to-end categories. Test execution takes 45 minutes, and you're seeing increasing flaky test issues. You need to optimize test strategy, improve reliability, and ensure adequate coverage for new features.

How MCP Azure DevOps helps:
The assistant can analyze test results, identify patterns in test failures, suggest test optimization strategies, and help maintain high-quality test suites.

Detailed workflow:

"Analyze our test suite performance and reliability for the last 60 days. Identify flaky tests, gaps in coverage, and suggest a strategy to reduce test execution time while maintaining quality. Focus on the checkout and payment modules."

The assistant will:

Test Performance Analysis:
- Analyze test execution times and trends
- Identify slowest and most unreliable tests
- Compare coverage metrics across modules
- Track test maintenance burden
Quality and Reliability Assessment:
- Identify flaky tests and failure patterns
- Analyze test coverage gaps
- Review test data management strategies
- Assess test environment stability
Optimization Strategy:
- Recommend test parallelization approaches
- Suggest test categorization and prioritization
- Propose improved test data management
- Design feedback loop optimization

Sample Test Analysis Report:

📊 Test Suite Health Dashboard (60-day analysis)

Overall Metrics:

Total Tests: 1,547 tests
Total Execution Time: 45.3 minutes (↑23% from 2 months ago)
Success Rate: 89.7% (target: 95%+)
Flaky Test Rate: 6.8% (105 tests)
Coverage: 78.4% (target: 85%)

⚠️ Problematic Test Categories:

Flaky Tests (Top 10):

1. CheckoutIntegrationTests.CompleteOrderWithPayPal
   Failure Rate: 23% | Avg Duration: 12.3s
   Issue: External PayPal API timeouts
   Recommendation: Mock external dependencies, add retry logic

2. PaymentServiceTests.ProcessRefundAsync  
   Failure Rate: 18% | Avg Duration: 8.7s
   Issue: Database state conflicts
   Recommendation: Improve test isolation, use test containers

3. UserAccountTests.LoginWithSocialProvider
   Failure Rate: 15% | Avg Duration: 15.2s  
   Issue: OAuth provider rate limiting
   Recommendation: Use test doubles for OAuth integration

Slowest Test Categories:

1. End-to-End Checkout Tests (avg: 3.2 min/test)
   - 23 tests taking 73.6 minutes total
   - Main bottleneck: Full browser automation
   - Optimization: Headless browser, API-level validation

2. Database Integration Tests (avg: 45s/test)
   - 89 tests taking 67 minutes total  
   - Main bottleneck: Database setup/teardown
   - Optimization: Test containers, parallel execution

3. External API Integration Tests (avg: 38s/test)
   - 34 tests taking 21.5 minutes total
   - Main bottleneck: Network latency, rate limiting
   - Optimization: Mock external services, contract testing

📈 Coverage Analysis:

Module Coverage Report:

WELL-COVERED MODULES (>85% coverage):
✅ Core Business Logic: 92.3%
✅ Authentication Service: 89.7%  
✅ User Management: 87.4%

UNDER-COVERED MODULES (<70% coverage):
⚠️  Payment Processing: 68.9%
   - Missing error handling tests
   - Insufficient edge case coverage
   - No load testing for high-volume scenarios

⚠️  Notification System: 65.2%
   - Limited integration testing
   - Missing failure recovery tests
   - No performance validation

⚠️  Reporting Module: 61.8%
   - Complex queries not tested
   - Missing data validation tests
   - Performance regression risks

🎯 Test Optimization Strategy:

Phase 1: Immediate Improvements (Week 1-2)

# 1. Parallel Test Execution Configuration
- task: VSTest@2
  displayName: 'Run Unit Tests'
  inputs:
    testAssemblyVer2: |
      **/*UnitTests.dll
      !**/obj/**
    parallel: true
    codeCoverageEnabled: true
    runInParallel: true

# 2. Test Categorization
[Category("Unit")]
[Category("Fast")] // <5 seconds
public class FastUnitTests { }

[Category("Integration")]  
[Category("Medium")] // 5-30 seconds
public class IntegrationTests { }

[Category("E2E")]
[Category("Slow")] // >30 seconds
public class EndToEndTests { }

Phase 2: Test Environment Optimization (Week 3-4)

// 3. Test Container Implementation
[SetUpFixture]
public class DatabaseTestFixture
{
    private static PostgreSqlContainer _container;

    [OneTimeSetUp]
    public async Task GlobalSetup()
    {
        _container = new PostgreSqlBuilder()
            .WithImage("postgres:13")
            .WithDatabase("testdb")
            .WithUsername("test")
            .WithPassword("test")
            .Build();

        await _container.StartAsync();
    }
}

// 4. Improved Test Isolation
public class PaymentServiceTests : IAsyncLifetime
{
    private readonly PaymentServiceTestFixture _fixture;

    public async Task InitializeAsync()
    {
        await _fixture.SeedTestDataAsync();
    }

    public async Task DisposeAsync()
    {
        await _fixture.CleanupTestDataAsync();
    }
}

Phase 3: Strategic Test Architecture (Week 5-8)

Test Pyramid Optimization:

CURRENT (problematic):
├── E2E Tests: 35% (539 tests) - Too many, too slow
├── Integration Tests: 25% (387 tests) - Appropriate
└── Unit Tests: 40% (621 tests) - Need more

OPTIMIZED TARGET:
├── E2E Tests: 10% (155 tests) - Critical user journeys only
├── Integration Tests: 20% (310 tests) - Key service boundaries  
└── Unit Tests: 70% (1,082 tests) - Comprehensive business logic

Contract Testing Implementation:

// 5. API Contract Testing
[Test]
public async Task PaymentAPI_ShouldMaintainContract()
{
    var contract = await LoadContractAsync("payment-api-v1.json");
    var response = await _client.PostAsync("/api/payments", testPayload);

    AssertContractCompliance(response, contract);
}

// 6. Mock External Dependencies  
public class PayPalServiceMock : IPayPalService
{
    public Task<PaymentResult> ProcessPaymentAsync(PaymentRequest request)
    {
        // Deterministic responses based on test scenarios
        return Task.FromResult(new PaymentResult 
        { 
            Success = true, 
            TransactionId = "test-tx-123" 
        });
    }
}

📊 Expected Improvements:

Performance Gains:

CURRENT STATE:
- Total execution time: 45.3 minutes
- Flaky test rate: 6.8%
- Parallel capability: 30%

PROJECTED IMPROVEMENTS:
- Optimized execution time: 12.8 minutes (-72%)
- Flaky test rate: <2% (-70%)
- Parallel capability: 85% (+55%)

QUALITY IMPROVEMENTS:
- Coverage increase: 78.4% → 87%+
- Faster feedback: 45min → 13min
- Reduced maintenance: -40% test debugging time

ROI Analysis:

DEVELOPER PRODUCTIVITY GAINS:
- Faster feedback loops: +25% development velocity
- Reduced test maintenance: 8h/week → 3h/week saved
- Improved confidence: Fewer production defects
- Cost savings: ~$75,000/year in developer time

6. Cross-Project Dependency Management and Release Coordination

Scenario: You're managing a microservices ecosystem with 12 services across 4 teams. A major feature requires coordinated changes across 6 services, each with different release cycles. You need to track dependencies, coordinate releases, and ensure compatibility across service boundaries.

How MCP Azure DevOps helps:
The assistant can analyze cross-project dependencies, track release compatibility, coordinate deployment schedules, and identify potential integration risks.

Detailed workflow:

"Analyze dependencies for the 'Customer Data Platform' initiative across all our microservices. Create a release coordination plan that ensures backward compatibility and minimizes deployment risks. Track the readiness of each service team."

The assistant will:

Dependency Mapping:
- Analyze service-to-service dependencies
- Track API version compatibility
- Identify shared database dependencies
- Map configuration and infrastructure requirements
Release Coordination:
- Plan deployment sequence based on dependencies
- Identify potential compatibility issues
- Coordinate testing across service boundaries
- Schedule feature flags and rollout strategies
Risk Assessment:
- Analyze blast radius of changes
- Identify single points of failure
- Plan rollback strategies
- Coordinate monitoring and alerting

Sample Dependency Analysis:

🏗️ Customer Data Platform - Cross-Service Dependency Analysis

Project Overview:

Initiative: Customer Data Platform (CDP) Integration
Affected Services: 6 of 12 microservices
Teams Involved: 4 teams (Platform, Customer, Analytics, Integration)
Target Release: Q2 2025
Estimated Timeline: 8 weeks

Service Dependency Map:

📊 DEPENDENCY HIERARCHY:

Tier 1 (Foundation Services):
├── customer-identity-service (v2.3.0 → v2.4.0)
│   ├── Breaking Changes: Authentication token format
│   ├── Team: Platform Team
│   └── Dependencies: None (foundational)

├── data-ingestion-service (v1.8.0 → v2.0.0)  
│   ├── Breaking Changes: Event schema updates
│   ├── Team: Platform Team
│   └── Dependencies: customer-identity-service

Tier 2 (Core Business Services):
├── customer-profile-service (v3.1.0 → v3.2.0)
│   ├── Breaking Changes: Profile API response format
│   ├── Team: Customer Team  
│   └── Dependencies: customer-identity-service, data-ingestion-service

├── analytics-engine-service (v1.5.0 → v1.6.0)
│   ├── Breaking Changes: None (backward compatible)
│   ├── Team: Analytics Team
│   └── Dependencies: customer-profile-service, data-ingestion-service

Tier 3 (Consumer Services):  
├── recommendation-service (v2.0.0 → v2.1.0)
│   ├── Breaking Changes: None
│   ├── Team: Customer Team
│   └── Dependencies: customer-profile-service, analytics-engine-service

├── notification-service (v1.3.0 → v1.4.0)
│   ├── Breaking Changes: None  
│   ├── Team: Integration Team
│   └── Dependencies: customer-profile-service

🚨 Critical Compatibility Issues Identified:

High Risk:

1. customer-identity-service Token Format Change
   Impact: All 11 downstream services affected
   Risk: Authentication failures, service outages
   Mitigation: Implement dual-token support for 2-week transition period

   Required Changes:
   - Update JWT validation logic in all consuming services
   - Implement backward compatibility layer
   - Coordinate token migration across all environments

2. data-ingestion-service Event Schema Breaking Changes
   Impact: Analytics pipelines, customer profile updates
   Risk: Data loss, processing failures
   Mitigation: Schema versioning with parallel processing

   Required Changes:
   - Support both v1 and v2 event schemas simultaneously
   - Implement schema migration tools
   - Update all event publishers to new format

Medium Risk:

3. customer-profile-service API Response Changes
   Impact: 5 consuming services need updates
   Risk: UI display issues, integration failures
   Mitigation: API versioning with gradual migration

   Required Changes:
   - Implement /v2/profile endpoints
   - Maintain /v1/profile for 6 months
   - Update consuming services incrementally

📅 Coordinated Release Plan:

Phase 1: Foundation (Weeks 1-2)

WEEK 1:
Day 1-2: customer-identity-service v2.4.0-beta
- Deploy to staging with dual-token support
- Begin integration testing with dependent services
- Validate backward compatibility

Day 3-5: data-ingestion-service v2.0.0-beta  
- Deploy schema versioning to staging
- Test parallel event processing (v1 + v2)
- Validate data integrity across both schemas

WEEK 2:
Day 1-3: Production deployment preparation
- Final integration testing
- Performance validation under load
- Rollback procedure testing

Day 4-5: Production deployment (Foundation Services)
- customer-identity-service v2.4.0 (with dual-token)
- data-ingestion-service v2.0.0 (with schema versioning)
- Monitor service health and compatibility

Phase 2: Core Services (Weeks 3-4)

WEEK 3:
Day 1-2: customer-profile-service v3.2.0-beta
- Deploy with /v2 API endpoints
- Maintain full backward compatibility
- Integration testing with foundation services

Day 3-5: analytics-engine-service v1.6.0-beta
- Deploy with new event processing logic
- Validate data pipeline functionality
- Performance testing with increased data volume

WEEK 4:
Day 1-2: Cross-service integration testing
- End-to-end workflow validation  
- Load testing across service boundaries
- Data consistency verification

Day 3-5: Production deployment (Core Services)
- Gradual rollout with feature flags
- Real-time monitoring and alerting
- Immediate rollback capability maintained

Phase 3: Consumer Services (Weeks 5-6)

WEEK 5-6: Consumer service updates
- recommendation-service v2.1.0
- notification-service v1.4.0  
- Incremental deployment with A/B testing
- User experience validation

Phase 4: Cleanup and Migration (Weeks 7-8)

WEEK 7-8: Legacy support removal
- Disable v1 token support in customer-identity-service
- Remove v1 event schema processing
- Deprecate /v1 API endpoints
- Performance optimization and monitoring refinement

🛡️ Risk Mitigation Strategies:

Deployment Safety Measures:

# Feature Flag Configuration
customer-data-platform:
  enabled: true
  rollout-percentage: 10  # Start with 10% traffic
  fallback-enabled: true
  monitoring-alerts: high-sensitivity

# Circuit Breaker Implementation  
services:
  customer-profile:
    circuit-breaker:
      failure-threshold: 5
      timeout: 10s
      fallback-response: cached-profile-data

Monitoring and Alerting:

CRITICAL METRICS TO MONITOR:
├── Service Health
│   ├── Response time increases >20%
│   ├── Error rate increases >1%
│   └── Service availability <99.9%
├── Data Integrity  
│   ├── Event processing success rate
│   ├── Profile data consistency checks
│   └── Schema migration progress
└── Business Impact
    ├── Customer authentication success rate
    ├── Profile update completion rate
    └── Recommendation service accuracy

Rollback Procedures:

AUTOMATED ROLLBACK TRIGGERS:
- Error rate >5% for 5 consecutive minutes
- Response time >2x baseline for 10 minutes  
- Data integrity violations detected
- Critical business metric degradation >10%

ROLLBACK SEQUENCE:
1. Immediate: Flip feature flags to disable new functionality
2. Quick (5 min): Redeploy previous service versions
3. Full (30 min): Database schema rollback if needed
4. Recovery: Data reconciliation and consistency repair

📊 Team Coordination Dashboard:

Team Readiness Status:

PLATFORM TEAM (2 services):
✅ customer-identity-service: Ready for deployment
   - Code complete, tests passing
   - Performance benchmarks met
   - Documentation updated

✅ data-ingestion-service: Ready for deployment  
   - Schema versioning implemented
   - Migration tools tested
   - Monitoring enhanced

CUSTOMER TEAM (2 services):
⚠️  customer-profile-service: 85% complete
   - API v2 implementation done
   - Missing: Load testing completion
   - ETA: End of week 2

✅ recommendation-service: Ready (dependent on profile service)
   - Integration tests complete
   - Backward compatibility verified

ANALYTICS TEAM (1 service):
✅ analytics-engine-service: Ready for deployment
   - New event processing logic complete
   - Performance validated
   - Dashboards updated

INTEGRATION TEAM (1 service):  
✅ notification-service: Ready for deployment
   - Customer profile integration updated
   - Message templates refreshed
   - Delivery metrics enhanced

Communication Plan:

STAKEHOLDER UPDATES:
├── Daily: Engineering team standup (technical status)
├── Bi-weekly: Product/Business stakeholders (progress & risks)
├── Weekly: Executive summary (timeline & business impact)
└── Ad-hoc: Critical issues or timeline changes

COMMUNICATION CHANNELS:
├── Slack: #customer-data-platform (real-time updates)
├── Email: Weekly progress reports
├── Dashboard: Real-time deployment status
└── Confluence: Detailed technical documentation

Success Metrics and KPIs:

TECHNICAL SUCCESS CRITERIA:
✅ Zero downtime deployment across all services
✅ <200ms average response time maintained  
✅ >99.9% availability during migration
✅ Data consistency validation 100% passed

BUSINESS SUCCESS CRITERIA:
✅ Customer authentication success rate >99.5%
✅ Profile update completion rate >98%
✅ Recommendation accuracy improvement >15%
✅ Customer satisfaction scores maintained

POST-DEPLOYMENT METRICS (30-day):
├── Service performance improvement: Target +25%
├── Development velocity improvement: Target +20%  
├── Cross-team collaboration efficiency: Target +30%
└── Technical debt reduction: Target -40%

Best Practices for Azure DevOps MCP Integration

Security and Access Management

Token Management:

Use fine-grained Personal Access Tokens with minimal required scopes
Implement token rotation policies (90-day maximum)
Store tokens securely using Azure Key Vault or similar services
Audit token usage and access patterns regularly

Permission Best Practices:

{
  "recommended-scopes": [
    "vso.work_write",           // Work item management
    "vso.code_read",            // Repository access
    "vso.build_read",           // Build pipeline monitoring
    "vso.test_read",            // Test result analysis
    "vso.project_read"          // Project information
  ],
  "avoid-scopes": [
    "vso.profile",              // Unnecessary for most use cases
    "vso.connected_server",     // High privilege, rarely needed
    "vso.machinegroup_manage"   // Infrastructure management
  ]
}

Performance Optimization

API Usage Patterns:

Implement intelligent caching for frequently accessed data
Use batch operations when possible to reduce API calls
Leverage OData filtering to minimize data transfer
Implement retry logic with exponential backoff

Resource Management:

// Example: Efficient work item querying
const workItemQuery = {
  wiql: `
    SELECT [System.Id], [System.Title], [System.State]
    FROM WorkItems 
    WHERE [System.TeamProject] = @project
    AND [System.State] <> 'Closed'
    AND [System.ChangedDate] >= @today-30
    ORDER BY [System.ChangedDate] DESC
  `,
  top: 200  // Limit results for performance
};

Integration Patterns

Workflow Integration:

Embed MCP capabilities into existing development workflows
Use consistent prompting patterns across teams
Implement automated quality gates with AI assistance
Create reusable templates for common operations

Team Collaboration:

Establish clear guidelines for AI-assisted code reviews
Document AI-generated insights and decisions
Maintain human oversight for critical business decisions
Share successful prompt patterns across teams

Advanced Scenarios and Future Possibilities

Predictive Analytics

Leverage historical Azure DevOps data to predict:

Sprint completion likelihood based on current progress
Potential quality issues based on code change patterns
Resource allocation optimization for upcoming projects
Risk assessment for complex feature implementations

Automated Reporting

Generate comprehensive reports for:

Executive dashboards with business-relevant metrics
Team performance analytics and improvement suggestions
Compliance and audit trail documentation
Customer impact assessment for changes

Integration Ecosystem

Future enhancements may include:

Integration with Azure Monitor for comprehensive observability
Connection to Azure Cognitive Services for enhanced analytics
Power BI integration for advanced data visualization
Microsoft Teams integration for seamless collaboration

Conclusion

The Azure DevOps MCP integration represents a transformative approach to enterprise development workflows. By providing AI assistants with deep, contextual access to your development processes, it enables unprecedented levels of automation, insight, and efficiency.

From intelligent work item management and sophisticated code review to complex release coordination and predictive analytics, MCP Azure DevOps empowers teams to focus on high-value creative work while AI handles routine analysis, coordination, and optimization tasks.

The detailed use cases presented in this article demonstrate the practical value of this integration across the entire software development lifecycle. Whether you're managing a small agile team or coordinating complex enterprise initiatives, Azure DevOps MCP provides the tools and intelligence needed to excel in today's fast-paced development environment.

As AI continues to evolve, the potential for even more sophisticated development assistance grows. The foundation provided by MCP Azure DevOps positions teams to leverage future AI capabilities while maintaining the security, compliance, and control requirements of enterprise environments.

Additional Resources

Ready to transform your Azure DevOps workflow with AI assistance? Here are the essential resources to get started:

Official Documentation

Azure DevOps REST API Documentation - Complete API reference
Model Context Protocol Specification - Technical protocol details

Setup and Configuration Guides

Personal Access Token Setup - Secure token configuration
VS Code GitHub Copilot MCP Integration - Development environment setup
Claude Desktop MCP Configuration - AI assistant integration

Community and Support

Azure DevOps Community - Community support and feedback
MCP Community Servers - Additional MCP server implementations
Azure DevOps Blog - Latest updates and best practices

Supercharge Your Development Workflow with MCP GitHub Integration

Mikael Krief — Mon, 18 Aug 2025 09:43:43 +0000

The Model Context Protocol (MCP) has revolutionized how AI assistants interact with external tools and services. One of the most powerful integrations available is the MCP GitHub connector, which bridges the gap between AI-powered development assistance and your GitHub repositories. In this article, we'll explore how to set up and leverage this integration with practical use cases that will transform your development workflow.

What is MCP GitHub?

The Model Context Protocol (MCP) is an open standard for connecting AI assistants to the systems where data lives, including content repositories, business tools, and development environments. MCP GitHub is a server implementation that allows AI assistants to interact directly with GitHub repositories through the GitHub API. This integration provides seamless access to repository contents, issues, pull requests, and other GitHub features, enabling AI assistants to understand your codebase context and assist with various development tasks.

Think of MCP as "a USB-C port for AI applications" - it provides a standardized way to connect AI models to different data sources and tools, with GitHub being one of the most powerful integrations available.

Setting Up MCP GitHub

Prerequisites

Before getting started, you'll need:

A GitHub account with appropriate repository access
A GitHub Personal Access Token (PAT) with necessary permissions
An MCP-compatible AI assistant (like Claude)

Installation and Configuration

GitHub now provides an official MCP server that you can use in multiple ways:

Option 1: GitHub's Official MCP Server (Recommended)
GitHub has released their official MCP server which is currently in public preview.

Option 2: Community MCP Servers
Several community-maintained servers are available in the MCP servers repository.

Setup Steps:

Create a GitHub Personal Access Token:
- Navigate to GitHub Settings > Developer settings > Personal access tokens
- Generate a new token with appropriate scopes (repo, read:org, etc.)
Configure your AI assistant:
For Claude Desktop users, you can follow the official MCP setup guide.

Example configuration:

{
  "servers": {
    "github": {
      "command": "mcp-server-github",
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "your_token_here"
      }
    }
  }
}

For Copilot Users:
VS Code users can also leverage MCP servers with GitHub Copilot by following the VS Code MCP documentation.

Key Features and Capabilities

The MCP GitHub integration provides several powerful capabilities:

Repository browsing: Navigate and explore repository structure
File operations: Read, search, and analyze code files
Issue management: Create, update, and track issues
Pull request handling: Review, comment, and manage PRs
Branch operations: Switch between branches and compare changes
Search functionality: Find code, issues, or discussions across repositories

Practical Use Cases

1. Code Review and Analysis

Scenario: You need to review a large pull request with multiple file changes across different modules, and you're concerned about maintaining code quality, security, and consistency with existing patterns.

How MCP GitHub helps:
The AI assistant can automatically fetch the PR details, analyze the changed files, and provide comprehensive feedback on code quality, potential bugs, and adherence to best practices.

Detailed workflow:

"Can you review PR #123 in my repository and check for any potential security vulnerabilities, performance issues, and code style consistency?"

The assistant will:

Fetch PR context: Retrieve all changed files, commit messages, and PR description
Analyze code patterns: Compare against existing codebase patterns and team conventions
Security assessment: Identify potential SQL injection, XSS vulnerabilities, authentication issues
Performance review: Spot inefficient database queries, memory leaks, or bottlenecks
Code quality checks: Review for:
- Proper error handling
- Code duplication
- Function complexity
- Test coverage gaps
- Documentation completeness

Sample output:

"⚠️ In auth.js line 45: The user input is directly interpolated into SQL query. Consider using parameterized queries."
"🚀 Performance: The database query in users.service.js could benefit from indexing on the email field."
"📝 Missing JSDoc comments for the new calculateDiscount function."
"✅ Good: Proper error handling implemented throughout the payment module."

Advanced features:

Cross-reference with previous issues and bug reports
Suggest specific code improvements with examples
Check against team coding standards and linting rules
Validate that tests cover new functionality

2. Bug Triage and Investigation

Scenario: A critical production bug has been reported: "Users can't complete checkout - getting 500 errors." You need to quickly understand the issue, identify the root cause, and assess its impact.

How MCP GitHub helps:
The assistant can examine the issue description, search through related code files, check commit history, and provide insights into the root cause.

Detailed workflow:

"Investigate issue #456 about checkout failures. Look at the payment processing module, recent changes, and related error logs. Also check if similar issues have been reported before."

The assistant will:

Issue analysis: Parse the bug report, extract key details (error codes, user agents, timestamps)
Code investigation: Examine relevant modules (payment processing, checkout flow, API endpoints)
Change history review: Analyze recent commits that might have introduced the issue
Pattern matching: Search for similar historical issues and their resolutions
Impact assessment: Identify affected user segments and business impact
Dependency mapping: Check if the issue affects other system components

Investigation process:

Search commit history around the reported timeframe
Analyze error handling in payment processing code
Check for recent changes to checkout API endpoints
Review configuration changes or dependency updates
Cross-reference with monitoring data patterns

Sample investigation report:

🔍 Issue Analysis for #456:
- Error type: 500 Internal Server Error in payment processing
- Timeline: Started appearing after commit abc123 (deployed 2 hours ago)
- Affected code: src/services/payment-processor.js, line 89
- Root cause: New validation rule breaking for international addresses
- Similar issues: #234, #378 (both address-related)
- Impact: ~15% of checkout attempts failing
- Fix priority: Critical (revenue impact)
- Suggested fix: Update address validation regex to handle international formats

3. Documentation Generation

Scenario: Your API has grown significantly, but the documentation is outdated and scattered. You need comprehensive, up-to-date documentation that reflects the current codebase and is useful for both internal developers and external API consumers.

How MCP GitHub helps:
The assistant can analyze your codebase, understand the structure and functionality, and generate well-formatted documentation that accurately reflects your code.

Detailed workflow:

"Generate comprehensive API documentation for our user management and payment modules. Include endpoint descriptions, request/response examples, error codes, and usage guidelines."

The assistant will:

Code structure analysis: Map all API endpoints, routes, and handlers
Parameter extraction: Identify required/optional parameters, data types, and validation rules
Response modeling: Document response formats, status codes, and error scenarios
Example generation: Create realistic request/response examples
Integration guidelines: Explain authentication, rate limiting, and best practices

Generated documentation includes:

API Overview:

Base URL and versioning strategy
Authentication methods (API keys, OAuth, JWT)
Rate limiting policies
Common error response format

Endpoint Documentation:

## Create User
`POST /api/v1/users`

Creates a new user account with the provided information.

### Request Headers
- `Content-Type: application/json`
- `Authorization: Bearer {token}`

### Request Body

json
{
"email": "user@example.com",
"password": "securePassword123",
"firstName": "John",
"lastName": "Doe",
"preferences": {
"notifications": true,
"newsletter": false
}
}


### Response (201 Created)

json
{
"id": "usr_1234567890",
"email": "user@example.com",
"firstName": "John",
"lastName": "Doe",
"createdAt": "2024-01-15T10:30:00Z",
"status": "active"
}


### Error Responses
- `400 Bad Request`: Invalid email format or missing required fields
- `409 Conflict`: User with this email already exists
- `422 Unprocessable Entity`: Password doesn't meet security requirements

Additional documentation features:

SDK examples in multiple languages (JavaScript, Python, cURL)
Postman collection generation
OpenAPI/Swagger specification
Integration tutorials and quickstart guides

4. Refactoring Assistance

Scenario: You're planning to modernize a legacy authentication system built 3 years ago. The code is tightly coupled, lacks proper separation of concerns, and uses outdated patterns. You need to understand the full scope before making changes.

How MCP GitHub helps:
The assistant can analyze the entire codebase, map dependencies, identify affected areas, and suggest a safe refactoring strategy.

Detailed workflow:

"I want to refactor our authentication system from session-based to JWT tokens. Show me all the files that depend on the current auth module, identify potential breaking changes, and suggest a migration plan."

The assistant will:

Dependency mapping: Trace all files that import or use the auth module
Impact analysis: Identify components that will be affected by the changes
Breaking change detection: Find areas where API contracts might change
Migration strategy: Propose a step-by-step refactoring approach
Risk assessment: Highlight high-risk areas and suggest mitigation strategies

Comprehensive analysis output:

Current Architecture Analysis:

📊 Authentication System Dependencies:
├── Core Auth Module (src/auth/)
│   ├── session-manager.js (12 files depend on this)
│   ├── user-validator.js (8 files depend on this)
│   └── auth-middleware.js (23 files depend on this)
├── API Routes (15 endpoints affected)
├── Frontend Components (9 React components)
└── Database Schema (3 tables involved)

Detailed Dependency Tree:

High Impact Files (require significant changes):
- src/middleware/auth-middleware.js - Used by all protected routes
- src/services/user-service.js - Handles user session management
- client/src/contexts/AuthContext.js - Frontend authentication state
Medium Impact Files (minor modifications needed):
- Route handlers for login/logout
- User profile components
- Admin dashboard authentication

Suggested Migration Plan:

Phase 1 - Preparation (1-2 days):
- Create JWT utilities and middleware
- Add JWT secret to environment configuration
- Write comprehensive tests for new auth flow
Phase 2 - Backend Migration (3-5 days):
- Implement JWT generation on login
- Update auth middleware to support both sessions and JWT
- Migrate API endpoints one by one
- Deploy with feature flags
Phase 3 - Frontend Migration (2-3 days):
- Update AuthContext to use tokens instead of cookies
- Modify API client to include Authorization headers
- Update login/logout flows
Phase 4 - Cleanup (1-2 days):
- Remove session-based code
- Clean up unused dependencies
- Update documentation

Risk Mitigation Strategies:

Maintain backward compatibility during transition
Implement comprehensive monitoring
Use feature flags for gradual rollout
Prepare rollback procedures

5. Code Quality Auditing

Scenario: Your development team has grown from 3 to 15 developers over the past year. Code consistency has suffered, and you want to establish better coding standards while identifying existing issues across the entire codebase.

How MCP GitHub helps:
The assistant can scan your entire repository, identify code smells, suggest improvements, and even help establish coding standards based on your team's best practices.

Detailed workflow:

"Audit our React codebase for common anti-patterns, inconsistent styling approaches, and performance issues. Also suggest team coding standards based on our best-written components."

The assistant will:

Pattern analysis: Identify recurring code patterns and inconsistencies
Performance audit: Find components that could cause performance issues
Best practice evaluation: Compare code against React best practices
Consistency check: Analyze coding styles and naming conventions
Standard recommendations: Suggest team guidelines based on existing good code

Comprehensive audit report:

🔍 Code Quality Analysis Results:

Anti-patterns Detected:

Prop Drilling (Found in 23 components):

   // ❌ Bad: Deep prop drilling
   <UserProfile user={user} updateUser={updateUser} deleteUser={deleteUser} />

   // ✅ Better: Use Context or state management
   <UserProfileProvider>
     <UserProfile />
   </UserProfileProvider>

Direct DOM Manipulation (8 instances):

   // ❌ Bad: Direct DOM manipulation
   document.getElementById('modal').style.display = 'block';

   // ✅ Better: React state-driven approach
   const [showModal, setShowModal] = useState(false);

Memory Leaks (12 components):
- Missing cleanup in useEffect hooks
- Event listeners not removed on unmount
- Timers and intervals not cleared

Performance Issues:

Unnecessary Re-renders: 31 components missing React.memo or useMemo
Large Bundle Sizes: 5 components importing entire libraries
Inefficient State Updates: 18 components with complex state mutations

Inconsistency Issues:

Naming Conventions: Mix of camelCase, PascalCase, and kebab-case
Import Organization: Inconsistent import ordering and grouping
Error Handling: Different error handling patterns across components
Styling Approaches: Mix of CSS modules, styled-components, and inline styles

Suggested Team Standards:

1. Component Structure:

// Recommended component template
import React, { useState, useEffect, useMemo } from 'react';
import PropTypes from 'prop-types';
import styles from './Component.module.css';

const ComponentName = ({ prop1, prop2, ...props }) => {
  // Hooks
  const [state, setState] = useState('');

  // Computed values
  const computedValue = useMemo(() => {
    return expensiveCalculation(prop1);
  }, [prop1]);

  // Effects
  useEffect(() => {
    // Effect logic with cleanup
    return () => {
      // Cleanup
    };
  }, []);

  // Event handlers
  const handleClick = useCallback(() => {
    // Handler logic
  }, []);

  return (
    <div className={styles.container}>
      {/* JSX */}
    </div>
  );
};

ComponentName.propTypes = {
  prop1: PropTypes.string.isRequired,
  prop2: PropTypes.number
};

export default ComponentName;

2. Performance Guidelines:

Use React.memo for expensive components
Implement proper dependency arrays in hooks
Lazy load components and routes
Optimize bundle sizes with proper imports

3. Code Organization:

Group imports: React → Third-party → Internal → Styles
Use absolute imports with path mapping
Consistent file and folder naming (kebab-case)
Co-locate related files (component + styles + tests)

6. Release Planning and Change Analysis

Scenario: You're preparing for version 3.0 of your e-commerce platform. It's been 4 months since v2.5, with 127 commits from 8 developers. You need to understand what's changed, assess risks, and create comprehensive release notes for different audiences (technical team, product managers, customers).

How MCP GitHub helps:
The assistant can analyze commits, PRs, and issues between releases, generate changelogs, and identify potential risks or breaking changes.

Detailed workflow:

"Generate a comprehensive release analysis for version 3.0 based on all changes since the v2.5 tag. Include technical changelog, user-facing improvements, potential risks, and migration guidelines."

The assistant will:

Change aggregation: Collect all commits, PRs, and closed issues since last release
Categorization: Group changes by type (features, fixes, improvements, breaking changes)
Impact assessment: Analyze changes for user impact and technical implications
Risk evaluation: Identify potential issues and breaking changes
Documentation generation: Create release notes for different audiences

Comprehensive Release Analysis:

📈 Release Summary v3.0:

Development Period: 4 months (March - June 2024)
Contributors: 8 developers
Commits: 127 commits
Pull Requests: 43 merged
Issues Resolved: 67 issues

🆕 Major Features:

Advanced Product Filtering (#234, #245, #267)
- Multi-attribute filtering with faceted search
- Performance improvements for large catalogs
- User Impact: Better product discovery, 40% faster search results
Guest Checkout Flow (#198, #203, #221)
- Complete checkout without account creation
- Streamlined form validation
- User Impact: Reduced cart abandonment by ~25%
Subscription Management (#156, #189, #201)
- Recurring payment handling
- Customer subscription dashboard
- User Impact: New revenue stream, better customer retention

🔧 Technical Improvements:

Database Optimization: Query performance improved by 60%
API Response Times: Average latency reduced from 350ms to 180ms
Bundle Size: JavaScript bundle reduced by 30% through code splitting
Security Updates: Upgraded 12 dependencies with security vulnerabilities

🐛 Bug Fixes (23 total):

Fixed payment processing edge cases (#178, #195)
Resolved mobile checkout layout issues (#188, #202)
Corrected inventory calculation errors (#165, #174)

⚠️ Breaking Changes & Migration Guide:

API Endpoint Changes:

   // ❌ Deprecated (will be removed in v3.5)
   GET /api/products/search?q=term

   // ✅ New endpoint
   POST /api/products/search
   Body: { query: "term", filters: {...} }

Configuration Updates:

   # Update your .env file
   # Old
   PAYMENT_PROVIDER=stripe

   # New (supports multiple providers)
   PAYMENT_PROVIDERS=stripe,paypal,square
   PRIMARY_PAYMENT_PROVIDER=stripe

Database Migration:
- New tables: subscriptions, product_attributes, search_indices
- Modified tables: orders (added subscription_id), products (added metadata)
- Migration time: ~5-10 minutes for medium databases

🚨 Risk Assessment:

High Risk:

Payment API changes require thorough testing
Database migrations on large datasets
New checkout flow needs extensive QA

Medium Risk:

Search functionality changes may affect user behavior
Subscription features are new and need monitoring

Low Risk:

UI improvements are mostly cosmetic
Performance optimizations are backward compatible

📋 Pre-deployment Checklist:

[ ] Run database migration in staging environment
[ ] Update API client libraries and documentation
[ ] Configure monitoring for new subscription features
[ ] Prepare rollback procedures for critical components
[ ] Update customer support documentation

🎯 Success Metrics to Monitor:

Checkout completion rates (target: >85%)
Search result click-through rates (target: >12%)
API response times (target: <200ms avg)
Subscription signup conversion (target: >5%)

📢 Customer-Facing Release Notes:

## What's New in Version 3.0

### 🛍️ Better Shopping Experience
- **Smart Product Search**: Find exactly what you're looking for with our new advanced filtering system
- **Quick Checkout**: Shop as a guest - no account required for one-time purchases
- **Faster Performance**: Pages load 40% faster with our optimized infrastructure

### 💡 New Features
- **Subscription Products**: Set up recurring deliveries for your favorite items
- **Enhanced Mobile Experience**: Improved checkout flow on phones and tablets
- **Better Recommendations**: More accurate product suggestions based on your preferences

### 🔧 Improvements & Fixes
- Resolved payment processing issues that affected some international customers
- Fixed mobile layout problems on checkout pages
- Improved inventory accuracy and real-time stock updates

7. Feature Breakdown and Issue Creation

Scenario: You have a large feature requirement and need to break it down into manageable tasks and create corresponding GitHub issues.

How MCP GitHub helps:
The assistant can analyze the feature description, break it down into logical components, consider dependencies, and automatically create well-structured issues with appropriate labels, assignments, and milestones.

Example workflow:

"I need to implement a user notification system with email and push notifications, user preferences, and an admin dashboard. Break this down into individual tasks and create GitHub issues for each component."

The assistant will:

Analyze the feature scope: Understand the requirements and identify main components
Break down into subtasks: Create logical divisions like:
- Backend API for notification service
- Email notification implementation
- Push notification setup
- User preference UI/UX
- Admin dashboard frontend
- Database schema updates
- Integration tests
- Documentation updates
Create structured issues: Generate issues with:
- Clear, descriptive titles
- Detailed descriptions with acceptance criteria
- Appropriate labels (backend, frontend, database, etc.)
- Estimated effort/story points
- Dependencies between issues
- Links to related documentation or designs
Organize with project management:
- Create a milestone for the feature
- Set up a project board if needed
- Establish proper issue relationships

Sample created issues:

[Backend] Implement notification service API endpoints
[Frontend] Create user notification preferences page
[DevOps] Set up push notification service integration
[Database] Add notification tables and relationships
[Testing] Write integration tests for notification system

This approach ensures nothing is overlooked, provides clear scope for each developer, and maintains traceability from feature to implementation.

8. Onboarding New Team Members

Scenario: A new developer joins your team and needs to understand the codebase architecture.

How MCP GitHub helps:
The assistant can provide architectural overviews, explain key components, and create guided tours of the codebase.

"Create an onboarding guide for our e-commerce platform that explains the main components and how they interact."

Best Practices for Using MCP GitHub

Security Considerations

Use fine-grained personal access tokens with minimal required permissions
Regularly rotate your access tokens
Never commit tokens to version control
Consider using organization-level tokens for team environments

Performance Optimization

Be specific in your requests to avoid unnecessary API calls
Use repository-specific contexts when possible
Leverage caching mechanisms when available

Collaboration Guidelines

Establish clear guidelines for AI-assisted code reviews
Maintain human oversight for critical decisions
Document AI-generated suggestions and decisions
Use consistent prompting patterns across your team

Advanced Workflows

Automated Code Review Pipeline

Set up workflows where the AI assistant automatically reviews pull requests, checks for common issues, and provides initial feedback before human review.

Intelligent Issue Routing

Use the assistant to analyze new issues, categorize them appropriately, and assign them to the most suitable team members based on expertise and workload.

Continuous Documentation Updates

Implement workflows that automatically update documentation when code changes are detected, ensuring your docs stay current with your codebase.

Limitations and Considerations

While MCP GitHub is powerful, it's important to understand its limitations:

API Rate Limits: GitHub API has rate limits that may affect intensive operations
Context Size: Very large repositories may exceed context windows
Real-time Sync: Changes made outside the assistant may not be immediately visible
Permissions: The assistant's capabilities are limited by the access token's permissions

Future Possibilities

The MCP GitHub integration continues to evolve, with potential future enhancements including:

Integration with GitHub Actions for CI/CD workflows
Enhanced project management features
Advanced analytics and reporting capabilities
Integration with GitHub Copilot and other AI tools

Conclusion

The MCP GitHub integration represents a significant leap forward in AI-assisted development. By seamlessly connecting AI assistants with your GitHub repositories, it enables more intelligent, context-aware assistance that can dramatically improve productivity and code quality.

Whether you're conducting code reviews, investigating bugs, generating documentation, or onboarding new team members, MCP GitHub provides the tools and context needed to work more efficiently and effectively.

Start experimenting with these use cases in your own projects, and discover how AI-powered development assistance can transform your workflow. The future of software development is collaborative, and MCP GitHub is helping to make that future a reality today.

Additional Resources

Ready to get started? Here are the key resources to help you implement MCP GitHub:

Official MCP Documentation - Comprehensive guide to the Model Context Protocol
GitHub's Official MCP Server - GitHub's official implementation (Public Preview)
Model Context Protocol Specification - Technical specification and protocol details
GitHub MCP Server Documentation - Official GitHub documentation for using the MCP server
Claude Desktop MCP Setup Guide - How to configure MCP in Claude Desktop
VS Code MCP Integration - Using MCP servers with GitHub Copilot in VS Code
Community MCP Servers - Collection of community-maintained MCP servers
GitHub Blog: Practical MCP Guide - Recent practical guide from GitHub

Begin integrating AI-powered assistance into your development workflow today with MCP GitHub and experience the future of collaborative software development.

Azure AKS and VNET Integration: A Comprehensive Guide

Mikael Krief — Fri, 04 Jul 2025 08:35:34 +0000

Introduction

Azure Kubernetes Service (AKS) is Microsoft's managed Kubernetes offering that simplifies the deployment, management, and operations of Kubernetes clusters in Azure. When building enterprise-grade applications, one of the most critical aspects is network security and isolation. This is where Virtual Network (VNET) integration becomes essential.

VNET integration allows your AKS cluster to communicate securely with other Azure resources while providing network-level isolation and control. In this article, we'll explore the various aspects of AKS and VNET integration, including different networking models, configuration options, and best practices.

Understanding how to properly integrate AKS with Azure Virtual Networks is crucial for:

Security: Implementing network segmentation and access controls
Compliance: Meeting organizational and regulatory requirements
Performance: Optimizing network traffic and reducing latency
Scalability: Planning for future growth and resource expansion

AKS Networking Models

1. Kubenet Networking

Kubenet is the basic networking plugin that provides simple network connectivity for AKS clusters. In this model:

Node IP addresses: Assigned from the Azure VNET subnet
Pod IP addresses: Assigned from a logically different address space
Network Address Translation (NAT): Used for pod-to-internet communication
Route tables: Azure manages routing between nodes and pods

Advantages of Kubenet:

Simple configuration and management
Lower IP address consumption in the VNET
Suitable for development and testing environments

Limitations of Kubenet:

Limited integration with Azure networking features
Complex routing for advanced scenarios
Potential performance impact due to NAT

2. Azure Container Networking Interface (CNI)

Azure CNI provides advanced networking capabilities by assigning IP addresses from the VNET to both nodes and pods:

Direct IP assignment: Pods receive IP addresses directly from the VNET subnet
Native VNET integration: Pods can communicate directly with VNET resources
Network policies: Support for Kubernetes network policies
Service integration: Direct integration with Azure Load Balancer and Application Gateway

Advantages of Azure CNI:

Better performance with direct networking
Enhanced security with network policies
Seamless integration with Azure services
Support for advanced networking features

Considerations for Azure CNI:

Higher IP address consumption
More complex IP address planning required
Potential for IP address exhaustion in large clusters

VNET Integration Configurations

Basic VNET Integration

For basic VNET integration, you need to:

Create a VNET with appropriate subnets:

   # Create resource group
   az group create --name myResourceGroup --location eastus

Explanation: Creates a new Azure resource group named myResourceGroup in the East US region. Resource groups are logical containers that hold related Azure resources.

Terraform equivalent:

   resource "azurerm_resource_group" "main" {
     name     = "myResourceGroup"
     location = "East US"
   }

   # Create VNET
   az network vnet create \
     --resource-group myResourceGroup \
     --name myVnet \
     --address-prefixes 10.0.0.0/8 \
     --subnet-name myAKSSubnet \
     --subnet-prefix 10.240.0.0/16

Explanation: Creates a virtual network with a large address space (10.0.0.0/8) and an initial subnet (10.240.0.0/16) specifically for AKS nodes. The large address space allows for future expansion and multiple subnets.

Terraform equivalent:

   resource "azurerm_virtual_network" "main" {
     name                = "myVnet"
     address_space       = ["10.0.0.0/8"]
     location            = azurerm_resource_group.main.location
     resource_group_name = azurerm_resource_group.main.name
   }

   resource "azurerm_subnet" "aks" {
     name                 = "myAKSSubnet"
     resource_group_name  = azurerm_resource_group.main.name
     virtual_network_name = azurerm_virtual_network.main.name
     address_prefixes     = ["10.240.0.0/16"]
   }

Deploy AKS cluster with VNET integration:

   # Get subnet ID
   SUBNET_ID=$(az network vnet subnet show \
     --resource-group myResourceGroup \
     --vnet-name myVnet \
     --name myAKSSubnet \
     --query id -o tsv)

Explanation: Retrieves the unique resource ID of the AKS subnet. This ID is required when creating the AKS cluster to specify which subnet the nodes should be placed in.

Terraform equivalent:

   # In Terraform, you can reference the subnet ID directly
   # using: azurerm_subnet.aks.id

   # Create AKS cluster
   az aks create \
     --resource-group myResourceGroup \
     --name myAKSCluster \
     --network-plugin azure \
     --vnet-subnet-id $SUBNET_ID \
     --docker-bridge-address 172.17.0.1/16 \
     --dns-service-ip 10.2.0.10 \
     --service-cidr 10.2.0.0/24

Explanation: Creates an AKS cluster with Azure CNI networking. Key parameters:

--network-plugin azure: Enables Azure CNI for advanced networking features
--vnet-subnet-id: Specifies the subnet for node placement
--docker-bridge-address: Internal Docker bridge network (must not overlap with VNET)
--dns-service-ip: IP address for the cluster DNS service
--service-cidr: CIDR range for Kubernetes services (must not overlap with VNET)

Terraform equivalent:

   resource "azurerm_kubernetes_cluster" "main" {
     name                = "myAKSCluster"
     location            = azurerm_resource_group.main.location
     resource_group_name = azurerm_resource_group.main.name
     dns_prefix          = "myakscluster"

     default_node_pool {
       name           = "default"
       node_count     = 1
       vm_size        = "Standard_D2_v2"
       vnet_subnet_id = azurerm_subnet.aks.id
     }

     network_profile {
       network_plugin     = "azure"
       dns_service_ip     = "10.2.0.10"
       service_cidr       = "10.2.0.0/24"
       docker_bridge_cidr = "172.17.0.1/16"
     }

     identity {
       type = "SystemAssigned"
     }
   }

Advanced VNET Integration with Multiple Subnets

For production environments, consider using multiple subnets:

# Create additional subnets
az network vnet subnet create \
  --resource-group myResourceGroup \
  --vnet-name myVnet \
  --name myInternalSubnet \
  --address-prefixes 10.241.0.0/16

Explanation: Creates an additional subnet for internal services and resources that need network isolation from the AKS nodes but still require VNET connectivity.

Terraform equivalent:

resource "azurerm_subnet" "internal" {
  name                 = "myInternalSubnet"
  resource_group_name  = azurerm_resource_group.main.name
  virtual_network_name = azurerm_virtual_network.main.name
  address_prefixes     = ["10.241.0.0/16"]
}

az network vnet subnet create \
  --resource-group myResourceGroup \
  --vnet-name myVnet \
  --name myApplicationGatewaySubnet \
  --address-prefixes 10.242.0.0/24

Explanation: Creates a dedicated subnet for Azure Application Gateway. Application Gateway requires its own subnet and cannot share it with other resources.

Terraform equivalent:

resource "azurerm_subnet" "appgw" {
  name                 = "myApplicationGatewaySubnet"
  resource_group_name  = azurerm_resource_group.main.name
  virtual_network_name = azurerm_virtual_network.main.name
  address_prefixes     = ["10.242.0.0/24"]
}

Private AKS Clusters

Private AKS clusters provide enhanced security by making the API server accessible only from within the VNET:

az aks create \
  --resource-group myResourceGroup \
  --name myPrivateAKSCluster \
  --network-plugin azure \
  --vnet-subnet-id $SUBNET_ID \
  --enable-private-cluster \
  --private-dns-zone "privatelink.eastus.azmk8s.io"

Explanation: Creates a private AKS cluster where the Kubernetes API server is only accessible from within the VNET or connected networks. Key parameters:

--enable-private-cluster: Makes the API server private
--private-dns-zone: Specifies a custom private DNS zone for the API server endpoint

Terraform equivalent:

resource "azurerm_kubernetes_cluster" "private" {
  name                = "myPrivateAKSCluster"
  location            = azurerm_resource_group.main.location
  resource_group_name = azurerm_resource_group.main.name
  dns_prefix          = "myprivateaks"
  private_cluster_enabled = true
  private_dns_zone_id     = "privatelink.eastus.azmk8s.io"

  default_node_pool {
    name           = "default"
    node_count     = 1
    vm_size        = "Standard_D2_v2"
    vnet_subnet_id = azurerm_subnet.aks.id
  }

  network_profile {
    network_plugin = "azure"
  }

  identity {
    type = "SystemAssigned"
  }
}

Network Security and Policies

Network Security Groups (NSGs)

Configure NSGs to control traffic flow:

# Create NSG
az network nsg create \
  --resource-group myResourceGroup \
  --name myAKSSecurityGroup

Explanation: Creates a Network Security Group (NSG) which acts as a basic firewall containing access control rules. NSGs can be associated with subnets or individual network interfaces to filter network traffic.

Terraform equivalent:

resource "azurerm_network_security_group" "aks" {
  name                = "myAKSSecurityGroup"
  location            = azurerm_resource_group.main.location
  resource_group_name = azurerm_resource_group.main.name
}

# Add rule for HTTPS traffic
az network nsg rule create \
  --resource-group myResourceGroup \
  --nsg-name myAKSSecurityGroup \
  --name AllowHTTPS \
  --direction inbound \
  --priority 1000 \
  --source-address-prefixes '*' \
  --destination-port-ranges 443 \
  --access allow \
  --protocol tcp

Explanation: Creates an inbound security rule that allows HTTPS traffic (port 443) from any source. The priority determines rule evaluation order (lower numbers = higher priority).

Terraform equivalent:

resource "azurerm_network_security_rule" "allow_https" {
  name                        = "AllowHTTPS"
  priority                    = 1000
  direction                   = "Inbound"
  access                      = "Allow"
  protocol                    = "Tcp"
  source_port_range           = "*"
  destination_port_range      = "443"
  source_address_prefix       = "*"
  destination_address_prefix  = "*"
  resource_group_name         = azurerm_resource_group.main.name
  network_security_group_name = azurerm_network_security_group.aks.name
}

Kubernetes Network Policies

Implement micro-segmentation within your cluster:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-ingress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress: []
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080

Integration with Azure Services

Azure Application Gateway Integration

Azure Application Gateway provides Layer 7 load balancing and web application firewall capabilities:

# Create Application Gateway subnet
az network vnet subnet create \
  --resource-group myResourceGroup \
  --vnet-name myVnet \
  --name myAppGatewaySubnet \
  --address-prefixes 10.242.0.0/24

Explanation: Creates a dedicated subnet for Azure Application Gateway. This subnet must be used exclusively for the Application Gateway and cannot contain other resources.

Terraform equivalent:

resource "azurerm_subnet" "appgw" {
  name                 = "myAppGatewaySubnet"
  resource_group_name  = azurerm_resource_group.main.name
  virtual_network_name = azurerm_virtual_network.main.name
  address_prefixes     = ["10.242.0.0/24"]
}

# Enable Application Gateway Ingress Controller
az aks enable-addons \
  --resource-group myResourceGroup \
  --name myAKSCluster \
  --addons ingress-appgw \
  --appgw-subnet-id $APPGW_SUBNET_ID

Explanation: Enables the Application Gateway Ingress Controller (AGIC) add-on on the AKS cluster. This creates an Application Gateway in the specified subnet and configures it as an ingress controller for the cluster.

Terraform equivalent:

resource "azurerm_kubernetes_cluster" "main" {
  # ... other configuration ...

  ingress_application_gateway {
    subnet_id = azurerm_subnet.appgw.id
  }
}

# Or as a separate resource for existing clusters
resource "azurerm_kubernetes_cluster_extension" "appgw_ingress" {
  name           = "appgw-ingress"
  cluster_id     = azurerm_kubernetes_cluster.main.id
  extension_type = "Microsoft.Web/sites"

  configuration_settings = {
    "appgw.subnetId" = azurerm_subnet.appgw.id
  }
}

Azure Load Balancer Integration

Configure Azure Load Balancer for external access:

apiVersion: v1
kind: Service
metadata:
  name: my-service
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-internal: "true"
    service.beta.kubernetes.io/azure-load-balancer-internal-subnet: "myInternalSubnet"
spec:
  type: LoadBalancer
  ports:
  - port: 80
    targetPort: 8080
  selector:
    app: my-app

Azure Private Link Integration

Enable private connectivity to Azure PaaS services:

# Create private endpoint for Azure SQL Database
az network private-endpoint create \
  --resource-group myResourceGroup \
  --name myPrivateEndpoint \
  --vnet-name myVnet \
  --subnet myInternalSubnet \
  --private-connection-resource-id $SQL_SERVER_RESOURCE_ID \
  --group-ids sqlServer \
  --connection-name myPrivateConnection

Explanation: Creates a private endpoint that allows secure access to Azure SQL Database over a private IP address within your VNET. This eliminates the need to access the database over the public internet.

Terraform equivalent:

resource "azurerm_private_endpoint" "sql" {
  name                = "myPrivateEndpoint"
  location            = azurerm_resource_group.main.location
  resource_group_name = azurerm_resource_group.main.name
  subnet_id           = azurerm_subnet.internal.id

  private_service_connection {
    name                           = "myPrivateConnection"
    private_connection_resource_id = var.sql_server_resource_id
    subresource_names              = ["sqlServer"]
    is_manual_connection           = false
  }
}

Testing VNET Integration

Once your AKS cluster is deployed with VNET integration, it's essential to validate that the networking configuration is working correctly. This section provides practical examples for testing various aspects of VNET integration.

Testing Basic Connectivity

1. Validate Pod-to-Pod Communication

Create test pods to verify internal cluster communication:

# test-pod-1.yaml
apiVersion: v1
kind: Pod
metadata:
  name: test-pod-1
  labels:
    app: test-connectivity
spec:
  containers:
  - name: network-test
    image: busybox
    command: ["sleep", "3600"]
---
# test-pod-2.yaml
apiVersion: v1
kind: Pod
metadata:
  name: test-pod-2
  labels:
    app: test-connectivity
spec:
  containers:
  - name: network-test
    image: busybox
    command: ["sleep", "3600"]

Deploy and test connectivity:

# Deploy test pods
kubectl apply -f test-pod-1.yaml
kubectl apply -f test-pod-2.yaml

Explanation: Deploys the test pod manifests to the Kubernetes cluster. kubectl apply creates or updates resources based on the YAML definitions.

Terraform equivalent:

resource "kubernetes_pod" "test_pod_1" {
  metadata {
    name = "test-pod-1"
    labels = {
      app = "test-connectivity"
    }
  }

  spec {
    container {
      image = "busybox"
      name  = "network-test"
      command = ["sleep", "3600"]
    }
  }
}

resource "kubernetes_pod" "test_pod_2" {
  metadata {
    name = "test-pod-2"
    labels = {
      app = "test-connectivity"
    }
  }

  spec {
    container {
      image = "busybox"
      name  = "network-test"
      command = ["sleep", "3600"]
    }
  }
}

# Get pod IPs
kubectl get pods -o wide

Explanation: Lists all pods with additional details including their assigned IP addresses, node placement, and status.

# Test ping between pods
kubectl exec test-pod-1 -- ping -c 3 <test-pod-2-ip>

Explanation: Executes a ping command inside test-pod-1 to test network connectivity to test-pod-2. The -c 3 parameter limits the ping to 3 packets.

# Test DNS resolution
kubectl exec test-pod-1 -- nslookup test-pod-2

Explanation: Tests DNS resolution within the cluster by looking up the hostname of test-pod-2 from test-pod-1.

2. Test External Connectivity

Verify internet access and external DNS resolution:

# Test external connectivity
kubectl exec test-pod-1 -- ping -c 3 8.8.8.8

Explanation: Tests internet connectivity by pinging Google's public DNS server (8.8.8.8) from within the pod.

# Test DNS resolution
kubectl exec test-pod-1 -- nslookup google.com

Explanation: Tests external DNS resolution by resolving the google.com domain name.

# Test HTTPS connectivity
kubectl exec test-pod-1 -- wget -O- https://www.microsoft.com

Explanation: Tests HTTPS connectivity by downloading the Microsoft homepage. This verifies both DNS resolution and HTTPS traffic flow.

Testing Azure Service Integration

1. Test Azure SQL Database Connectivity

Create a test pod to verify database connectivity:

# sql-test-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: sql-test-pod
spec:
  containers:
  - name: sql-test
    image: mcr.microsoft.com/mssql-tools
    command: ["sleep", "3600"]
    env:
    - name: SQL_SERVER
      value: "your-server.database.windows.net"
    - name: SQL_DATABASE
      value: "your-database"
    - name: SQL_USER
      value: "your-username"
    - name: SQL_PASSWORD
      valueFrom:
        secretKeyRef:
          name: sql-secret
          key: password

Test the connection:

# Deploy the test pod
kubectl apply -f sql-test-pod.yaml

Explanation: Deploys a test pod with SQL Server tools to test database connectivity.

Terraform equivalent:

resource "kubernetes_pod" "sql_test" {
  metadata {
    name = "sql-test-pod"
  }

  spec {
    container {
      image = "mcr.microsoft.com/mssql-tools"
      name  = "sql-test"
      command = ["sleep", "3600"]

      env {
        name  = "SQL_SERVER"
        value = "your-server.database.windows.net"
      }

      env {
        name  = "SQL_DATABASE"
        value = "your-database"
      }

      env {
        name  = "SQL_USER"
        value = "your-username"
      }

      env {
        name = "SQL_PASSWORD"
        value_from {
          secret_key_ref {
            name = "sql-secret"
            key  = "password"
          }
        }
      }
    }
  }
}

# Test SQL connection
kubectl exec sql-test-pod -- /opt/mssql-tools/bin/sqlcmd \
  -S $SQL_SERVER \
  -d $SQL_DATABASE \
  -U $SQL_USER \
  -P $SQL_PASSWORD \
  -Q "SELECT 1"

Explanation: Executes sqlcmd inside the test pod to connect to Azure SQL Database and run a simple query. This validates that the pod can reach the database through the private endpoint.

2. Test Azure Storage Integration

Verify connectivity to Azure Storage accounts:

# Test storage account connectivity
kubectl run storage-test --image=mcr.microsoft.com/azure-cli \
  --command -- sleep 3600

Explanation: Creates a pod with Azure CLI tools to test connectivity to Azure Storage services.

Terraform equivalent:

resource "kubernetes_pod" "storage_test" {
  metadata {
    name = "storage-test"
  }

  spec {
    container {
      image   = "mcr.microsoft.com/azure-cli"
      name    = "azure-cli"
      command = ["sleep", "3600"]
    }
  }
}

# Test blob storage access
kubectl exec storage-test -- az storage blob list \
  --account-name yourstorageaccount \
  --container-name yourcontainer \
  --account-key youraccountkey

Explanation: Lists blobs in an Azure Storage container to verify that pods can access Azure Storage services through the network configuration.

Testing Network Policies

1. Deploy Test Applications

Create applications to test network policy enforcement:

# frontend-app.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend
spec:
  replicas: 1
  selector:
    matchLabels:
      app: frontend
  template:
    metadata:
      labels:
        app: frontend
        tier: frontend
    spec:
      containers:
      - name: frontend
        image: nginx
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: frontend-service
spec:
  selector:
    app: frontend
  ports:
  - port: 80
    targetPort: 80
---
# backend-app.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: backend
spec:
  replicas: 1
  selector:
    matchLabels:
      app: backend
  template:
    metadata:
      labels:
        app: backend
        tier: backend
    spec:
      containers:
      - name: backend
        image: nginx
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: backend-service
spec:
  selector:
    app: backend
  ports:
  - port: 80
    targetPort: 80

2. Test Without Network Policies

# Deploy applications
kubectl apply -f frontend-app.yaml
kubectl apply -f backend-app.yaml

# Test connectivity before applying policies
kubectl exec deployment/frontend -- curl -s backend-service

3. Apply Network Policy and Test

# network-policy-test.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-netpol
spec:
  podSelector:
    matchLabels:
      tier: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          tier: frontend
    ports:
    - protocol: TCP
      port: 80

Test policy enforcement:

# Apply network policy
kubectl apply -f network-policy-test.yaml

# Test allowed connectivity (should work)
kubectl exec deployment/frontend -- curl -s backend-service

# Test denied connectivity (should fail)
kubectl run test-denied --image=busybox --command -- sleep 3600
kubectl exec test-denied -- wget -qO- backend-service

Testing Private Cluster Access

1. Verify API Server Access

Test access to the private API server:

# From a VM in the same VNET
kubectl get nodes

# Test API server endpoint resolution
nslookup your-aks-cluster-api-fqdn

# Verify private endpoint connectivity
curl -k https://your-aks-cluster-api-fqdn/api/v1

2. Test Jump Box Connectivity

Create a jump box to test private cluster access:

# Create jump box VM in the same VNET
az vm create \
  --resource-group myResourceGroup \
  --name jumpbox \
  --image UbuntuLTS \
  --vnet-name myVnet \
  --subnet jumpbox-subnet \
  --admin-username azureuser \
  --generate-ssh-keys

Explanation: Creates a Linux virtual machine in the same VNET as the private AKS cluster. This VM acts as a jump box to access the private cluster since the API server is not accessible from the internet.

Terraform equivalent:

resource "azurerm_subnet" "jumpbox" {
  name                 = "jumpbox-subnet"
  resource_group_name  = azurerm_resource_group.main.name
  virtual_network_name = azurerm_virtual_network.main.name
  address_prefixes     = ["10.243.0.0/24"]
}

resource "azurerm_public_ip" "jumpbox" {
  name                = "jumpbox-pip"
  resource_group_name = azurerm_resource_group.main.name
  location            = azurerm_resource_group.main.location
  allocation_method   = "Static"
}

resource "azurerm_network_interface" "jumpbox" {
  name                = "jumpbox-nic"
  location            = azurerm_resource_group.main.location
  resource_group_name = azurerm_resource_group.main.name

  ip_configuration {
    name                          = "testconfiguration1"
    subnet_id                     = azurerm_subnet.jumpbox.id
    private_ip_address_allocation = "Dynamic"
    public_ip_address_id          = azurerm_public_ip.jumpbox.id
  }
}

resource "azurerm_linux_virtual_machine" "jumpbox" {
  name                = "jumpbox"
  resource_group_name = azurerm_resource_group.main.name
  location            = azurerm_resource_group.main.location
  size                = "Standard_B1s"
  admin_username      = "azureuser"

  disable_password_authentication = true

  network_interface_ids = [
    azurerm_network_interface.jumpbox.id,
  ]

  admin_ssh_key {
    username   = "azureuser"
    public_key = file("~/.ssh/id_rsa.pub")
  }

  os_disk {
    caching              = "ReadWrite"
    storage_account_type = "Standard_LRS"
  }

  source_image_reference {
    publisher = "Canonical"
    offer     = "0001-com-ubuntu-server-focal"
    sku       = "20_04-lts"
    version   = "latest"
  }
}

# Install kubectl on jump box
ssh azureuser@jumpbox-ip
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl

Explanation: SSH into the jump box and install kubectl, the Kubernetes command-line tool needed to interact with the AKS cluster.

# Configure kubectl with AKS credentials
az aks get-credentials --resource-group myResourceGroup --name myAKSCluster

Explanation: Downloads the cluster configuration and credentials, configuring kubectl to connect to the private AKS cluster.

# Test cluster access
kubectl get nodes
kubectl get pods --all-namespaces

Explanation: Verifies that kubectl can successfully connect to the private cluster by listing nodes and pods.

Testing Load Balancer and Ingress

1. Test LoadBalancer Service

Deploy a test application with LoadBalancer service:

# loadbalancer-test.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: lb-test-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: lb-test
  template:
    metadata:
      labels:
        app: lb-test
    spec:
      containers:
      - name: web
        image: nginx
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: lb-test-service
spec:
  type: LoadBalancer
  selector:
    app: lb-test
  ports:
  - port: 80
    targetPort: 80

Test the LoadBalancer:

# Deploy the test application
kubectl apply -f loadbalancer-test.yaml

# Get external IP
kubectl get service lb-test-service

# Test external access
curl http://<external-ip>

# Test load balancing
for i in {1..10}; do curl http://<external-ip>; done

2. Test Application Gateway Ingress

Create an ingress resource for testing:

# ingress-test.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test-ingress
  annotations:
    kubernetes.io/ingress.class: azure/application-gateway
spec:
  rules:
  - host: test.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: lb-test-service
            port:
              number: 80

Test ingress functionality:

# Apply ingress resource
kubectl apply -f ingress-test.yaml

# Get ingress status
kubectl get ingress test-ingress

# Test with host header
curl -H "Host: test.example.com" http://<ingress-ip>

Network Diagnostics and Troubleshooting

1. Network Connectivity Troubleshooting

Use diagnostic pods for network troubleshooting:

# Deploy network troubleshooting pod
kubectl run netshoot --image=nicolaka/netshoot --command -- sleep 3600

# Network diagnostics commands
kubectl exec netshoot -- ping <target-ip>
kubectl exec netshoot -- traceroute <target-ip>
kubectl exec netshoot -- nslookup <hostname>
kubectl exec netshoot -- netstat -tulpn
kubectl exec netshoot -- ss -tulpn

2. DNS Resolution Testing

# Test cluster DNS
kubectl exec netshoot -- nslookup kubernetes.default.svc.cluster.local

# Test external DNS
kubectl exec netshoot -- nslookup google.com

# Check DNS configuration
kubectl exec netshoot -- cat /etc/resolv.conf

3. Performance Testing

Test network performance between pods:

# Deploy iperf3 server
kubectl run iperf3-server --image=networkstatic/iperf3 -- iperf3 -s

# Deploy iperf3 client and test
kubectl run iperf3-client --image=networkstatic/iperf3 -- sleep 3600

# Get server IP
SERVER_IP=$(kubectl get pod iperf3-server -o jsonpath='{.status.podIP}')

# Run performance test
kubectl exec iperf3-client -- iperf3 -c $SERVER_IP -t 30

Validation Checklist

Use this checklist to validate your VNET integration:

[ ] Pods can communicate with each other within the cluster
[ ] Pods can access external internet resources
[ ] DNS resolution works correctly for internal and external services
[ ] Azure services are accessible from pods (if configured)
[ ] Network policies are enforced correctly
[ ] LoadBalancer services are accessible externally
[ ] Ingress controllers route traffic properly
[ ] Private cluster API server is accessible only from authorized networks
[ ] NSG rules are working as expected
[ ] No unnecessary network ports are exposed

Best Practices and Recommendations

IP Address Planning

Reserve sufficient IP addresses: Plan for cluster scaling and pod density
Use non-overlapping CIDR blocks: Avoid conflicts with on-premises networks
Consider future growth: Allocate larger subnets than immediately needed

Example IP planning:

VNET: 10.0.0.0/8
├── AKS Subnet: 10.240.0.0/16 (65,536 IPs)
├── Internal Services: 10.241.0.0/16 (65,536 IPs)
├── Application Gateway: 10.242.0.0/24 (256 IPs)
└── Management: 10.243.0.0/24 (256 IPs)

Security Considerations

Implement defense in depth:
- Use NSGs for subnet-level filtering
- Apply Kubernetes Network Policies for pod-level segmentation
- Enable Azure Policy for governance
Use private clusters for production:

   az aks create \
     --enable-private-cluster \
     --enable-managed-identity \
     --enable-rbac

Explanation: Creates a production-ready AKS cluster with enhanced security features:

--enable-private-cluster: API server only accessible from private networks
--enable-managed-identity: Uses Azure managed identity for secure authentication
--enable-rbac: Enables Kubernetes role-based access control for fine-grained permissions

Terraform equivalent:

   resource "azurerm_kubernetes_cluster" "production" {
     name                    = "production-aks"
     location                = azurerm_resource_group.main.location
     resource_group_name     = azurerm_resource_group.main.name
     dns_prefix              = "production-aks"
     private_cluster_enabled = true

     default_node_pool {
       name       = "default"
       node_count = 3
       vm_size    = "Standard_D2_v2"
     }

     identity {
       type = "SystemAssigned"
     }

     role_based_access_control_enabled = true
   }

Secure container registry access:

   # Create private endpoint for ACR
   az acr create \
     --resource-group myResourceGroup \
     --name myRegistry \
     --sku Premium \
     --public-network-enabled false

Explanation: Creates an Azure Container Registry with private endpoint capability:

--sku Premium: Required for private endpoint support and advanced features
--public-network-enabled false: Disables public access, forcing all access through private endpoints

Terraform equivalent:

   resource "azurerm_container_registry" "main" {
     name                     = "myRegistry"
     resource_group_name      = azurerm_resource_group.main.name
     location                 = azurerm_resource_group.main.location
     sku                      = "Premium"
     public_network_access_enabled = false
   }

   resource "azurerm_private_endpoint" "acr" {
     name                = "acr-private-endpoint"
     location            = azurerm_resource_group.main.location
     resource_group_name = azurerm_resource_group.main.name
     subnet_id           = azurerm_subnet.internal.id

     private_service_connection {
       name                           = "acr-privateserviceconnection"
       private_connection_resource_id = azurerm_container_registry.main.id
       subresource_names              = ["registry"]
       is_manual_connection           = false
     }
   }

Monitoring and Troubleshooting

Enable Container Insights:

   az aks enable-addons \
     --resource-group myResourceGroup \
     --name myAKSCluster \
     --addons monitoring

Explanation: Enables Azure Monitor Container Insights for the AKS cluster, providing comprehensive monitoring of cluster performance, resource utilization, and application logs.

Terraform equivalent:

   resource "azurerm_log_analytics_workspace" "main" {
     name                = "aks-logs"
     location            = azurerm_resource_group.main.location
     resource_group_name = azurerm_resource_group.main.name
     sku                = "PerGB2018"
   }

   resource "azurerm_kubernetes_cluster" "main" {
     # ... other configuration ...

     oms_agent {
       log_analytics_workspace_id = azurerm_log_analytics_workspace.main.id
     }
   }

Use Network Watcher for troubleshooting:

   # Enable Network Watcher
   az network watcher configure \
     --resource-group myResourceGroup \
     --locations eastus \
     --enabled

Explanation: Enables Azure Network Watcher in the specified region. Network Watcher provides network monitoring, diagnostic, and analytics tools to help troubleshoot network connectivity issues.

Terraform equivalent:

   resource "azurerm_network_watcher" "main" {
     name                = "NetworkWatcher_eastus"
     location            = "East US"
     resource_group_name = azurerm_resource_group.main.name
   }

Monitor network performance:
- Track pod-to-pod communication latency
- Monitor ingress/egress bandwidth
- Set up alerts for network anomalies

Performance Optimization

Choose appropriate VM sizes: Select VM SKUs with adequate network performance
Enable accelerated networking: Improve network performance for supported VM sizes
Optimize pod placement: Use node affinity and anti-affinity rules
Implement horizontal pod autoscaling: Scale based on network metrics

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 3
  maxReplicas: 100
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

Conclusion

Azure AKS and VNET integration is a fundamental component of enterprise Kubernetes deployments on Azure. By properly implementing VNET integration, organizations can achieve:

Enhanced Security: Network-level isolation and access controls provide multiple layers of protection
Improved Performance: Direct networking reduces latency and improves application responsiveness
Seamless Integration: Native connectivity with Azure services simplifies architecture design
Scalability: Proper IP planning and network design support future growth requirements

Key takeaways for successful AKS VNET integration:

Plan your network architecture carefully: Consider current requirements and future growth
Choose the right networking model: Azure CNI for advanced features, Kubenet for simplicity
Implement security best practices: Use NSGs, network policies, and private clusters
Monitor and optimize: Continuously monitor network performance and security

The choice between Kubenet and Azure CNI depends on your specific requirements, but for production workloads requiring advanced networking features and better integration with Azure services, Azure CNI is typically the preferred option.

As Kubernetes and Azure continue to evolve, staying informed about new networking features and best practices will help you maintain a secure, performant, and scalable container infrastructure.

References

Introducing AKS Automatic: Simplifying Kubernetes Management on Azure

Mikael Krief — Tue, 25 Mar 2025 10:29:10 +0000

Managing Kubernetes clusters can be complex, requiring expertise in security, performance tuning, and scalability. Microsoft has recently introduced AKS Automatic, a new feature in Azure Kubernetes Service (AKS) that automates cluster configuration and management. This new capability, currently in public preview, enables developers and DevOps teams to focus on their applications rather than cluster administration.

What is AKS Automatic?

AKS Automatic is a fully managed Kubernetes service that simplifies cluster operations by applying best practices for security, performance, and reliability. With this feature, AKS takes care of infrastructure management, ensuring that clusters are always optimized and running efficiently. This means less manual intervention for operations teams and more time for innovation.

Key Features of AKS Automatic

Automated Cluster Scaling
AKS Automatic dynamically adjusts the cluster size based on workload demands. This eliminates the need for manual scaling, ensuring optimal resource utilization and cost efficiency.
Built-in Security Best Practices
Security is a major concern in Kubernetes environments. AKS Automatic enforces security policies, including network isolation, role-based access control (RBAC), and automatic patching, reducing the risk of vulnerabilities.
Optimized Performance
The system continuously monitors and optimizes cluster performance, adjusting configurations based on workload patterns to maintain high availability and reliability.
Simplified Upgrades and Maintenance
One of the biggest challenges in managing Kubernetes is keeping clusters updated without causing downtime. AKS Automatic handles version upgrades, patches, and maintenance windows, ensuring a seamless experience for developers.

For more details on AKS Automatic, refer to the official Microsoft documentation.

How to Set Up and Test AKS Automatic?

Prerequisites

Before starting, ensure that you have:

Azure CLI installed and updated
kubectl installed
An Azure subscription
AKS Automatic feature enabled (as it's currently in preview)

For installation details, visit the Azure CLI documentation and kubectl installation guide.

Step 1: Enable the AKS Automatic Feature

First, install the necessary Azure CLI extension:

az extension add --name aks-preview
az extension update --name aks-preview

Then, register the Automatic SKU Preview feature:

az feature register --namespace Microsoft.ContainerService --name AutomaticSKUPreview

Check the feature status:

az feature show --namespace Microsoft.ContainerService --name AutomaticSKUPreview

Once the status changes to "Registered", refresh the provider registration:

az provider register --namespace Microsoft.ContainerService

For more details on enabling preview features, check this guide.

Step 2: Create a New AKS Automatic Cluster

Now, create a resource group:

az group create --name myResourceGroup --location eastus

Deploy a new AKS Automatic cluster:

az aks create \
    --resource-group myResourceGroup \
    --name myAKSAutomaticCluster \
    --sku automatic \
    --generate-ssh-keys

This will provision an AKS cluster with automatic management.

Step 3: Connect to the Cluster

Once your cluster is ready, connect to it using az cli and kubectl:

az account set ....
az aks get-credentials --resource-group myResourceGroup --name myAKSAutomaticCluster
kubelogin ....

Verify the cluster nodes:

kubectl get nodes

You should see nodes automatically provisioned and ready for workloads.

Step 4: Deploy a Sample Application

To test the cluster, deploy a sample Nginx application:

kubectl create deployment nginx --image=nginx

Expose the deployment via a LoadBalancer:

kubectl expose deployment nginx --port=80 --target-port=80 --type=LoadBalancer

Check the status:

kubectl get services

After a few moments, an external IP should be assigned to your service. You can then access it via a web browser.

Step 5: Test Auto-Scaling

AKS Automatic supports automatic scaling, so let’s test it.

Scale the deployment to 10 replicas:

kubectl scale deployment nginx --replicas=10

Check the pod distribution:

kubectl get pods -o wide

AKS Automatic should automatically adjust node count based on demand. To monitor this, use:

kubectl get nodes

Over time, AKS Automatic will optimize resource usage and scale the cluster accordingly.
For more information, see the AKS Auto-Scaling documentation.

Step 6: Monitor and Test Performance

To monitor the cluster, enable Azure Monitor for Containers:

az aks enable-addons --resource-group myResourceGroup --name myAKSAutomaticCluster --addons monitoring

Then, check the logs and metrics in the Azure Portal under the "Monitor" section.

For a full documentation on AKS monitoring, see Azure Monitor for Containers.

Final Thoughts

AKS Automatic is a game-changer for teams looking to simplify Kubernetes management while ensuring security and performance. By leveraging this new feature, organizations can streamline their DevOps workflows and accelerate application deployment without the operational burden of managing Kubernetes clusters.

Would you like a hands-on tutorial or a demo on AKS Automatic? Let us know in the comments!

For the latest updates and in-depth information, visit the official Azure Kubernetes Service documentation.

The Hangfire Cookbook: A Practical Guide to Background Job Processing in .NET and Azure

Mikael Krief — Sun, 16 Mar 2025 08:53:22 +0000

Hangfire is one of the most powerful background job processing libraries in the .NET ecosystem. Whether you're working with ASP.NET Core, .NET Framework, or integrating with Azure Services, Hangfire simplifies job scheduling, execution, and monitoring.

This cookbook-style guide combines fundamental, advanced, and integration recipes for mastering Hangfire in real-world .NET applications. Each recipe provides a use case, step-by-step implementation, and best practices.

📌 Chapter 1: Getting Started with Hangfire

1.1 Installing and Configuring Hangfire

Use Case

You need to set up Hangfire to handle background jobs in your .NET application.

Implementation

Install Hangfire via NuGet

   Install-Package Hangfire
   Install-Package Hangfire.SqlServer

Configure Hangfire in Program.cs (for .NET Core)

   builder.Services.AddHangfire(config => 
       config.UseSqlServerStorage("your_connection_string"));
   builder.Services.AddHangfireServer();
   app.UseHangfireDashboard();

Enqueue a Test Job

   BackgroundJob.Enqueue(() => Console.WriteLine("Hello from Hangfire!"));

Best Practices

✔ Use a persistent database like SQL Server or Redis instead of in-memory storage.

✔ Secure the Hangfire dashboard to prevent unauthorized access.

1.2 Job Types in Hangfire

Use Case

You want to execute different types of jobs such as one-time, delayed, recurring, or continuation jobs.

Implementation

✔ Fire-and-Forget Jobs

BackgroundJob.Enqueue(() => SendEmail("user@example.com"));

✔ Delayed Jobs

BackgroundJob.Schedule(() => GenerateReport(), TimeSpan.FromMinutes(30));

✔ Recurring Jobs

RecurringJob.AddOrUpdate("daily-report", () => GenerateDailyReport(), Cron.Daily);

✔ Continuation Jobs

var jobId = BackgroundJob.Enqueue(() => ProcessOrder());
BackgroundJob.ContinueWith(jobId, () => NotifyCustomer());

Best Practices

✔ Use queues for prioritizing job execution.

✔ Set timeouts and automatic retries to handle failures.

📌 Chapter 2: Advanced Hangfire Techniques

2.1 Handling Job Failures and Retries

Use Case

You need to handle job failures gracefully and implement custom retry mechanisms.

Implementation

✔ Customize Retries

[AutomaticRetry(Attempts = 3, OnAttemptsExceeded = AttemptsExceededAction.Fail)]
public void SendEmail()
{
    throw new Exception("SMTP server down!");
}

✔ Log Failed Jobs

public class LogFailureFilter : JobFilterAttribute, IServerFilter
{
    public void OnPerformed(PerformedContext context)
    {
        if (context.Exception != null)
        {
            Console.WriteLine($"Job {context.BackgroundJob.Id} failed: {context.Exception.Message}");
        }
    }
}

GlobalConfiguration.Configuration.UseFilter(new LogFailureFilter());

Best Practices

✔ Monitor failed jobs in the Hangfire Dashboard.

✔ Implement job continuation for failure handling.

2.2 Using Dependency Injection in Jobs

Use Case

You need to use services like Entity Framework, Email Services, or APIs in Hangfire jobs.

Implementation

✔ Resolve Services with IServiceScopeFactory

public class OrderProcessor
{
    private readonly IServiceScopeFactory _scopeFactory;

    public OrderProcessor(IServiceScopeFactory scopeFactory)
    {
        _scopeFactory = scopeFactory;
    }

    public void ProcessOrders()
    {
        using var scope = _scopeFactory.CreateScope();
        var dbContext = scope.ServiceProvider.GetRequiredService<AppDbContext>();
        var orders = dbContext.Orders.Where(o => o.Status == "Pending").ToList();

        foreach (var order in orders)
            order.Status = "Processed";

        dbContext.SaveChanges();
    }
}

✔ Enqueue Job

BackgroundJob.Enqueue<OrderProcessor>(job => job.ProcessOrders());

Best Practices

✔ Avoid directly injecting DbContext; always use scoped services.

✔ Implement transactional processing to avoid partial updates.

📌 Chapter 3: Using Hangfire in Azure

3.1 Storing Hangfire Jobs in Azure SQL

Use Case

You need to persist Hangfire jobs in Azure for scalability and reliability.

Implementation

✔ Configure Hangfire to Use Azure SQL

GlobalConfiguration.Configuration.UseSqlServerStorage("Azure_SQL_Connection_String");

Best Practices

✔ Use Azure SQL with Read Replicas to balance the load.

3.2 Processing Jobs with Azure Storage Queues

Use Case

You want to offload Hangfire jobs to Azure Storage Queues for better scalability.

Implementation

✔ Push Jobs to Azure Queue

var queueClient = new QueueClient("Azure_Storage_Connection_String", "job-queue");
queueClient.SendMessage("Start Processing Order");

✔ Process Queue Messages with Hangfire

BackgroundJob.Enqueue(() => ProcessQueueMessage());

Best Practices

✔ Use Azure Service Bus for complex job orchestration.

📌 Conclusion

This Hangfire Cookbook covered:

✅ Job scheduling & execution

✅ Advanced job processing techniques

✅ Integrating Hangfire with SignalR & Azure

✅ Security & performance best practices

Want to go further? Next article : Running Hangfire in Kubernetes (AKS) or Microservices! 🚀

Using Azure App Configuration for Enhancing .NET Application Configuration

Mikael Krief — Tue, 18 Feb 2025 08:58:09 +0000

As a .NET developer, you’ve likely worked extensively with the web.config file to manage application settings. Traditionally, keys in the AppSettings section have been the go-to for configuration needs. While this approach works well for simple setups, modern cloud-based applications demand more flexibility, scalability, and centralized configuration management. Azure App Configuration is a great tool to meet these requirements.

In this blog post, I’ll share how you can enhance your application’s configuration system by integrating Azure App Configuration alongside your existing web.config file, using ConfigurationBuilders. This approach ensures minimal code changes while significantly improving your configuration management. Importantly, this configuration will continue to support keys from AppSettings without requiring Azure App Configuration.

The Current Setup: web.config

The web.config file has been a cornerstone of .NET application configuration. Here’s an example of a typical AppSettings section:

<configuration>
  <appSettings>
    <add key="ApiUrl" value="https://api.example.com" />
    <add key="FeatureToggle" value="true" />
  </appSettings>
</configuration>

While this works for basic setups, managing configurations across multiple environments (e.g., development, staging, production) becomes challenging. You often end up duplicating configurations or manually updating them for each environment. This approach is error-prone and lacks centralized control.

Introducing Azure App Configuration

Azure App Configuration provides a centralized and scalable way to manage application settings. It allows you to store configuration values in a single location, making it easier to manage and update settings across environments.

Some key features include:

Centralized management of configuration settings.
Integration with Azure Key Vault for secure storage.
Versioning and labeling of settings for different environments.
Feature management capabilities.

The Challenge: Minimizing Code Changes

Migrating entirely to Azure App Configuration can be time-consuming, especially for legacy applications. To address this, we can use ConfigurationBuilders to integrate Azure App Configuration into the existing web.config setup seamlessly while ensuring that the application can still use values defined directly in AppSettings if Azure App Configuration is not available.

Using ConfigurationBuilders

ConfigurationBuilders is a feature introduced in .NET Framework 4.7.1 that allows dynamic configuration values to be injected into your application at runtime. By leveraging this feature, you can combine values from web.config, Azure App Configuration, and other sources without requiring major code changes.

Here’s how you can implement it:

1- Install the Required NuGet Packages

Add the following NuGet packages to your project:

Install-Package Microsoft.Configuration.ConfigurationBuilders.AzureAppConfiguration
Install-Package Microsoft.Configuration.ConfigurationBuilders.Environment

2- Modify the web.config File

Update your web.config file to use ConfigurationBuilders:

<configuration>
  <configBuilders>
    <builders>
      <add name="AzureConfigBuilder" 
           type="Microsoft.Configuration.ConfigurationBuilders.AzureAppConfigurationBuilder, Microsoft.Configuration.ConfigurationBuilders.AzureAppConfiguration" 
           connectionString="${ConnectionString}" 
           mode="greedy" 
           optional="true" />
      <add name="EnvironmentConfigBuilder" 
           type="Microsoft.Configuration.ConfigurationBuilders.EnvironmentConfigBuilder, Microsoft.Configuration.ConfigurationBuilders.Environment" 
           mode="greedy" />
    </builders>
  </configBuilders>

  <appSettings configBuilders="AzureConfigBuilder,EnvironmentConfigBuilder">
    <add key="ConnectionString" value="Endpoint=https://<your-app-config-name>.azconfig.io;Id=<id>;Secret=<secret>" />
    <add key="ApiUrl" value="https://api.example.com" />
    <add key="FeatureToggle" value="true" />
  </appSettings>
</configuration>

In this setup:

The configBuilders section specifies both AzureAppConfigurationBuilderand EnvironmentConfigBuilder.
The connectionString is referenced using the ${ConnectionString} syntax, allowing it to be dynamically resolved from the AppSettings section.
The mode="greedy" attribute ensures that all matching keys from each builder are considered instead of stopping at the first match.
The optional="true" attribute ensures that the application continues to work even if Azure App Configuration is unavailable.
The EnvironmentConfigBuilder allows values to be overridden by environment variables.
Existing keys in AppSettings are augmented or overridden by values from Azure App Configuration or environment variables.

3- Add Settings to Azure App Configuration and Environment Variables

Navigate to your Azure App Configuration instance in the Azure Portal and add the required settings. Additionally, set environment variables for settings that you want to override dynamically.

For example:

Azure App Configuration:

Key: ApiUrl | Value: https://new-api.example.com
Key: FeatureToggle | Value: false

Environment Variables:

ApiUrl: https://env-api.example.com
FeatureToggle: true

4- Run and Test the Application

When your application runs, the ConfigurationBuildersdynamically fetch the settings from Azure App Configuration, environment variables, and the web.config file. The priority is determined by the order in which builders are listed in the configBuilders section.

Configuration Order

The effective configuration values are determined by the following priority, based on the order of ConfigurationBuilders in the web.config:

Azure App Configuration (AzureAppConfigurationBuilder)
Environment Variables (EnvironmentConfigBuilder)
web.config Values

By setting mode="greedy", all sources are checked, ensuring that no configuration values are missed, and all possible sources are used for retrieving settings.

Conclusion

By using ConfigurationBuilders with mode="greedy", you can ensure that all available configuration sources are considered when resolving keys. This approach enhances flexibility and ensures that your application dynamically adapts to available configurations while maintaining backward compatibility. Start enhancing your application today with Azure App Configuration and EnvironmentConfigBuilder for centralized and dynamic configuration management!

How to send logs to Azure Application Insights using log4net

Mikael Krief — Wed, 11 Dec 2024 09:45:46 +0000

I recently worked on a .Net application that sends its logs to files on the local file system using the log4Net Framework (see the documentation here).
With the objective of improving and centralising logs, we considered sending the logs to an Azure Application Insight.
Of course, we can use the App Insight SDK, but to avoid multiplying the code, we decided to extend Log4nNet by using a Log4Net appender dedicated to App Insight.
In this post walks you through the steps to configure Log4net with the Application Insights appender and view your logs in the Azure portal.

Prerequisites

Azure Application Insights: Set up a resource in the Azure portal.(see the documentation here)
The Instrumentation Key: Obtain the instrumentation key from your Application Insights resource. You’ll use this to send logs to Azure.

Install the Required NuGet Package

To enable logging from log4net to Application Insights, install the Microsoft.ApplicationInsights.Log4NetAppender package using the command or via Visual Studio Package Manager:

dotnet add package Microsoft.ApplicationInsights.Log4NetAppender

The package page is here
The package documentation is here

Update log4net.config or web.config

Modify your log4net.config (or web.config) file to include the Application Insights appender. Below is a sample configuration:

<log4net>
  <appender name="ApplicationInsightsAppender" type="Microsoft.ApplicationInsights.Log4NetAppender.ApplicationInsightsAppender, Microsoft.ApplicationInsights.Log4NetAppender">
    <param name="InstrumentationKey" value="**<your-instrumentation-key>**" />
    <layout type="log4net.Layout.PatternLayout">
      <conversionPattern value="%date [%thread] %-5level %logger - %message%newline" />
    </layout>
  </appender>
  <root>
    <level value="ALL" />
    <appender-ref ref="ApplicationInsightsAppender" />
  </root>
</log4net>

Replace your-instrumentation-key with the key from your Azure Application Insights resource.

You can also configure Telemetry directly in he code. Bellow a sample of telemetry configuration:

using Microsoft.ApplicationInsights.Extensibility;

TelemetryConfiguration configuration = TelemetryConfiguration.CreateDefault();
configuration.InstrumentationKey = "your-instrumentation";

Initialize log4net in Your Application

Ensure log4net is initialized when your application starts. Here’s an example for an ASP.NET application:

using log4net;

namespace YourNamespace
{
    public class Program
    {
        private static readonly ILog Log = LogManager.GetLogger(typeof(Program));

        public static void Main(string[] args)
        {
            Log.Info("Application is starting...");
            // Your code here
        }
    }
}

This ensures log4net reads from the log4net.config file and starts logging immediately.

Start your application and trigger log events.

View Logs in Azure Application Insights

Once your logs are being sent to Application Insights, you can explore and analyze them in the Azure portal. Here's how:

Go to Your Application Insights Resource
Open the left menu Transaction search
Click on the button "See all data in the last 24 hours"

The logs appear.

You can filter by date and event type of logs (trace, request, exception, ....).
Bellow a sample of logs in App Insight, that I filter to last 30 days logs and choose to display only logs of type Exceptions:

Troubleshooting Tips

Missing Logs: Double-check the instrumentation key and verify your application has network access to Azure.
Log Level Issues: Confirm the log level in your log4net.config matches your expectations (e.g., INFO, DEBUG, ERROR).
Debug Locally: Temporarily add a ConsoleAppender in log4net.config to verify logs are being generated locally.

Conclusion

Integrating log4net with Azure Application Insights is a powerful way to monitor your application's behavior. With these steps, you’ll have logging configured and the ability to explore logs in the Azure portal for faster debugging and optimization. You can even set up alerts to proactively monitor critical issues.

Mores resources

Testing provisioned Azure Resource with PowerShell Pester

Mikael Krief — Fri, 01 Nov 2024 13:55:56 +0000

In the fast-paced world of cloud computing, ensuring that your infrastructure is correctly provisioned is crucial. Azure Kubernetes Service (AKS) is a powerful tool for running containerized applications, but with that power comes the responsibility to ensure that your AKS cluster is provisioned and configured correctly. This is where PowerShell Pester comes in handy. Pester is a versatile testing framework for PowerShell that allows you to write unit tests, integration tests, and acceptance tests. In this blog post, we will explore how to use Pester to test Azure resources like AKS.

What is PowerShell Pester?

Pester is the testing framework built into PowerShell and is commonly used for validating scripts, modules, and other PowerShell components. It provides a simple syntax for creating tests, along with useful cmdlets for running those tests. Pester is particularly useful in DevOps pipelines, where automated tests can help prevent issues before they make it to production.

Key Features of Pester:

Lightweight: Pester is a small, quick-to-run framework, making it ideal for continuous integration and delivery pipelines.
Integration with CI/CD: Pester integrates seamlessly with Azure DevOps, Jenkins, and other CI/CD platforms.
Extensible: Pester can be extended with custom assertions and modules.

Why Test Azure Resources?

Testing Azure resources like AKS clusters is essential for several reasons:

Validation: Ensures that the resources have been provisioned with the correct configurations.
Compliance: Helps to maintain compliance with organizational policies and standards.
Early Detection: Identifies misconfigurations early in the deployment process, reducing the risk of issues in production.

Setting Up Pester for Azure

Before we can start writing tests, we need to set up our environment.

Prerequisites

Azure Subscription: You need an active Azure subscription.
PowerShell: Ensure you have the latest version of PowerShell installed.
Azure PowerShell Module: Install the Azure PowerShell module using the following command:

   Install-Module -Name Az -AllowClobber -Force

Pester Module: Pester is typically installed with PowerShell, but if you need to install or update it, use:

   Install-Module -Name Pester -Force -SkipPublisherCheck

AKS Cluster: Ensure that you have an AKS cluster provisioned in your Azure environment.

Authenticating to Azure

First, you need to authenticate to your Azure account:

Connect-AzAccount

This command will prompt you to log in to your Azure account and authenticate your session.

Writing Pester Tests for AKS

Now that your environment is set up, let’s dive into writing tests for an AKS cluster.

Example Test Cases

Here are some example scenarios you might want to test:

Verify AKS Cluster Existence: Ensure that the AKS cluster is provisioned.
Check Node Count: Confirm that the correct number of nodes are running.
Validate Kubernetes Version: Ensure the AKS cluster is running the expected Kubernetes version.
Check RBAC Configuration: Ensure that Role-Based Access Control (RBAC) is enabled.

Example Pester Tests

Below is an example of how to write Pester tests for these scenarios:

# Import the necessary modules
Import-Module Az
Import-Module Pester

# Define your test script
Describe "AKS Cluster Validation Tests" {

    $resourceGroupName = "MyResourceGroup"
    $aksClusterName = "MyAKSCluster"

    Context "AKS Cluster Existence" {
        It "Should find the AKS cluster in the specified resource group" {
            $aksCluster = Get-AzAksCluster -ResourceGroupName $resourceGroupName -Name $aksClusterName -ErrorAction SilentlyContinue
            $aksCluster | Should -Not -BeNullOrEmpty
        }
    }

    Context "Node Count Verification" {
        It "Should have the expected number of nodes" {
            $expectedNodeCount = 3
            $nodePools = Get-AzAksNodePool -ResourceGroupName $resourceGroupName -ClusterName $aksClusterName
            $totalNodes = ($nodePools | Measure-Object -Property Count).Sum
            $totalNodes | Should -Be $expectedNodeCount
        }
    }

    Context "Kubernetes Version Check" {
        It "Should be running the expected Kubernetes version" {
            $expectedVersion = "1.29.4"
            $aksCluster = Get-AzAksCluster -ResourceGroupName $resourceGroupName -Name $aksClusterName
            $aksCluster.KubernetesVersion | Should -Be $expectedVersion
        }
    }

    Context "RBAC Configuration" {
        It "Should have RBAC enabled" {
            $aksCluster = Get-AzAksCluster -ResourceGroupName $resourceGroupName -Name $aksClusterName
            $aksCluster.EnableRBAC | Should -Be $true
        }
    }
}

# Run the tests
Invoke-Pester

Explanation of the Script

Describe: This block groups related tests together. In this case, we group all tests related to the AKS cluster.
Context: This block allows you to organize tests within a Describe block. Each Context block contains related tests.
It: This block defines an individual test. The string inside the It block describes the test being performed.
Assertions (Should): These are the core of the tests. They compare actual values to expected values using various conditions like -Be, -Not, -Contain, etc.

Running the Tests

Once your tests are written, you can execute them by running the Invoke-Pester command in your PowerShell session. This will output the results of each test to the console, indicating which tests passed and which failed.

Example Output

Describing AKS Cluster Validation Tests
  Context AKS Cluster Existence
    [+] Should find the AKS cluster in the specified resource group 2.3s
  Context Node Count Verification
    [+] Should have the expected number of nodes 1.5s
  Context Kubernetes Version Check
    [+] Should be running the expected Kubernetes version 1.7s
  Context RBAC Configuration
    [+] Should have RBAC enabled 1.2s

In this output:

[+] indicates a passing test.
The time taken for each test is displayed for performance insights.

Integrating Pester with CI/CD

To fully leverage the power of Pester, integrate your tests into your CI/CD pipeline. For instance, in Azure DevOps, you can add a PowerShell task to run your Pester tests as part of the release pipeline. This ensures that your infrastructure is validated each time it’s deployed.

Example Azure DevOps YAML

steps:
- powershell: |
    Install-Module -Name Pester -Force
    Install-Module -Name Az -Force
    Connect-AzAccount -Identity
    Invoke-Pester -Script 'path\to\your\test.ps1'
  displayName: 'Run Pester Tests'

This step installs the necessary modules, authenticates to Azure, and runs your Pester tests.

Integrating Pester with GitHub Actions

Integrating Pester tests with CI/CD pipelines can enhance deployment reliability. Here's a basic GitHub Actions workflow for Pester:

name: Pester Tests

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
    - name: Checkout code
      uses: actions/checkout@v2

    - name: Setup PowerShell
      uses: PowerShell/setup-powershell@v1

    - name: Install Azure PowerShell module
      run: |
        pwsh -command 'Install-Module -Name Az -Scope CurrentUser -Force -Repository PSGallery'

    - name: Install Pester
      run: |
        pwsh -command 'Install-Module -Name Pester -Scope CurrentUser -Force'

    - name: Run Pester tests
      run: |
        pwsh -command 'Invoke-Pester -Path ./Tests'

Troubleshooting Common Testing Issues

Authentication Errors: Ensure that your Azure PowerShell is up-to-date and that you are properly authenticated using Connect-AzAccount.
Resource Not Found: Double-check your Resource Group names and Resource identifiers.
Permission Issues: Make sure your account has the necessary permissions to access and manage the resources you are testing.

Conclusion

Testing your Azure resources with Pester is a robust way to ensure that your infrastructure is deployed and configured correctly. By integrating these tests into your CI/CD pipeline, you can catch issues early and maintain a high standard of quality in your Azure deployments. Whether you’re testing an AKS cluster or other Azure services, Pester provides a flexible and powerful framework to keep your infrastructure in check.

Start writing your Pester tests today, and take control of your Azure infrastructure with confidence!