Bringing Azure Infrastructure into Kubernetes: Why ASO v2 is a Game Changer for GitOps

Infrastructure as Code (IaC) isn’t just a best practice in modern cloud environments, it’s essential. As systems scale, teams need automation, consistency, and strong security to avoid the pitfalls of manual provisioning. IaC makes your infrastructure repeatable, auditable, and self-service-friendly — all while speeding up delivery. Traditionally, tools like Terraform, Bicep, and ARM templates have been the standard for managing Azure infrastructure. But what if you could provision and manage your cloud resources the same way you manage your applications — using Kubernetes, CRDs, and GitOps workflows? That’s where Azure Service Operator v2 (ASO v2) comes in. What is ASO v2? Azure Service Operator v2 is the official, production-grade Kubernetes operator built by Microsoft for managing Azure resources using Kubernetes-native APIs. It allows you to define and manage Azure services (e.g., SQL Databases, Cosmos DB, Storage Accounts, Key Vaults) as Kubernetes Custom Resources — fully integrated with GitOps pipelines using tools like Flux and ArgoCD. Compared to the original ASO, version 2 brings: A modular, per-service architecture, so you can install only what you need Support for latest Azure API versions, mapped 1:1 to Azure's resource model Better multi-tenancy support and flexible identity management Improved controller reliability and reconciliation performance Why This Matters in a GitOps World GitOps has changed the way we ship and manage applications — but applying GitOps to infrastructure, especially stateful resources, is still challenging. Take a database, for example. Provisioning one isn’t just about spinning up a container. You also need: Data persistence Backup and restore policies Geo-replication Access controls and secrets Performance configuration Most infrastructure tools treat this separately from the application layer. That can lead to siloed pipelines, manual work, and config drift. ASO v2 brings infrastructure and app delivery together — in the same GitOps flow. You define resources declaratively, store them in Git, and Kubernetes takes care of syncing the desired state with Azure. How ASO v2 Works ASO v2 works by introducing Azure-specific Custom Resource Definitions (CRDs) into your Kubernetes cluster. For each supported Azure service, there’s a matching Kubernetes resource type. For example: SqlServer and SqlDatabase for Azure SQL StorageAccount for Azure Blob/File/Table storage KeyVault, CosmosDB, PostgreSqlDatabase, etc. Each of these resources is managed by a controller — a background process that: Watches for changes to the custom resources Validates desired state against current Azure state Makes API calls to Azure to bring the resource into alignment This means your Azure infrastructure becomes Kubernetes-native — you can kubectl apply a database, update it with a GitOps commit, and monitor it just like any other workload. Perfect for Hybrid Environments In real-world teams, hybrid environments are the norm: developers deploy applications, while platform teams manage infrastructure. ASO v2 helps bridge this gap by enabling: Self-service provisioning: Developers can request their own databases or Key Vaults — with guardrails — using YAML. Environment consistency: Staging, QA, and prod environments can be defined and reproduced identically. Policy enforcement: Teams can apply RBAC, Azure AD identities, and resource quotas at the Kubernetes level. You can even use different credentials per namespace, meaning each team or workload can authenticate with different Azure identities — perfect for multi-tenant clusters. Example: Provisioning an Azure SQL Database Here’s what an Azure SQL Database resource might look like using ASO v2: apiVersion: azure.microsoft.com/v1api20211101 kind: SqlDatabase metadata: name: my-database spec: location: eastus owner: name: my-sql-server collation: SQL_Latin1_General_CP1_CI_AS maxSizeBytes: 5368709120 # 5 GB sku: name: S1 tier: Standard capacity: 10 This lives alongside your app code and gets deployed via GitOps. Need to change the SKU or scale up storage? Just edit the file and commit. What ASO Can’t (Yet) Do ASO v2 is powerful, but it’s important to note a few things it doesn’t do — at least not yet: You can’t create a database from a backup directly in the CRD (like point-in-time restore or copy from another DB). This still needs to be done using CLI or ARM. Not all Azure services are supported yet (but the list is growing fast). It’s not a full replacement for Terraform/Bicep — rather, it's a GitOps-friendly complement that excels in app-adjacent infrastructure. Key Benefits for Teams GitOps-native Azure infrastructure Modular installation — only install the Azure services you need Fine-grained identity control using Azure AD Workload Identity Unified workflows for app + infra using Kubernetes-nat

Apr 7, 2025 - 18:07

Bringing Azure Infrastructure into Kubernetes: Why ASO v2 is a Game Changer for GitOps

Infrastructure as Code (IaC) isn’t just a best practice in modern cloud environments, it’s essential.

As systems scale, teams need automation, consistency, and strong security to avoid the pitfalls of manual provisioning. IaC makes your infrastructure repeatable, auditable, and self-service-friendly — all while speeding up delivery.

Traditionally, tools like Terraform, Bicep, and ARM templates have been the standard for managing Azure infrastructure. But what if you could provision and manage your cloud resources the same way you manage your applications — using Kubernetes, CRDs, and GitOps workflows?

That’s where Azure Service Operator v2 (ASO v2) comes in.

What is ASO v2?

Azure Service Operator v2 is the official, production-grade Kubernetes operator built by Microsoft for managing Azure resources using Kubernetes-native APIs.

It allows you to define and manage Azure services (e.g., SQL Databases, Cosmos DB, Storage Accounts, Key Vaults) as Kubernetes Custom Resources — fully integrated with GitOps pipelines using tools like Flux and ArgoCD.

Compared to the original ASO, version 2 brings:

A modular, per-service architecture, so you can install only what you need
Support for latest Azure API versions, mapped 1:1 to Azure's resource model
Better multi-tenancy support and flexible identity management
Improved controller reliability and reconciliation performance

Why This Matters in a GitOps World

GitOps has changed the way we ship and manage applications — but applying GitOps to infrastructure, especially stateful resources, is still challenging.

Take a database, for example. Provisioning one isn’t just about spinning up a container. You also need:

Data persistence
Backup and restore policies
Geo-replication
Access controls and secrets
Performance configuration

Most infrastructure tools treat this separately from the application layer. That can lead to siloed pipelines, manual work, and config drift.

ASO v2 brings infrastructure and app delivery together — in the same GitOps flow. You define resources declaratively, store them in Git, and Kubernetes takes care of syncing the desired state with Azure.

How ASO v2 Works

ASO v2 works by introducing Azure-specific Custom Resource Definitions (CRDs) into your Kubernetes cluster. For each supported Azure service, there’s a matching Kubernetes resource type. For example:

SqlServer and SqlDatabase for Azure SQL
StorageAccount for Azure Blob/File/Table storage
KeyVault, CosmosDB, PostgreSqlDatabase, etc.

Each of these resources is managed by a controller — a background process that:

Watches for changes to the custom resources
Validates desired state against current Azure state
Makes API calls to Azure to bring the resource into alignment

This means your Azure infrastructure becomes Kubernetes-native — you can kubectl apply a database, update it with a GitOps commit, and monitor it just like any other workload.

Perfect for Hybrid Environments

In real-world teams, hybrid environments are the norm: developers deploy applications, while platform teams manage infrastructure. ASO v2 helps bridge this gap by enabling:

Self-service provisioning: Developers can request their own databases or Key Vaults — with guardrails — using YAML.
Environment consistency: Staging, QA, and prod environments can be defined and reproduced identically.
Policy enforcement: Teams can apply RBAC, Azure AD identities, and resource quotas at the Kubernetes level.

You can even use different credentials per namespace, meaning each team or workload can authenticate with different Azure identities — perfect for multi-tenant clusters.

Example: Provisioning an Azure SQL Database

Here’s what an Azure SQL Database resource might look like using ASO v2:

apiVersion: azure.microsoft.com/v1api20211101
kind: SqlDatabase
metadata:
  name: my-database
spec:
  location: eastus
  owner:
    name: my-sql-server
  collation: SQL_Latin1_General_CP1_CI_AS
  maxSizeBytes: 5368709120  # 5 GB
  sku:
    name: S1
    tier: Standard
    capacity: 10

This lives alongside your app code and gets deployed via GitOps. Need to change the SKU or scale up storage? Just edit the file and commit.

What ASO Can’t (Yet) Do

ASO v2 is powerful, but it’s important to note a few things it doesn’t do — at least not yet:

You can’t create a database from a backup directly in the CRD (like point-in-time restore or copy from another DB). This still needs to be done using CLI or ARM.
Not all Azure services are supported yet (but the list is growing fast).
It’s not a full replacement for Terraform/Bicep — rather, it's a GitOps-friendly complement that excels in app-adjacent infrastructure.

Key Benefits for Teams

GitOps-native Azure infrastructure
Modular installation — only install the Azure services you need
Fine-grained identity control using Azure AD Workload Identity
Unified workflows for app + infra using Kubernetes-native tooling
Developer enablement with self-service infra provisioning

ASO v2 and Crossplane: Competing or Complementary?

As more teams adopt GitOps and Kubernetes-native infrastructure workflows, it's natural to compare tools like ASO v2 and Crossplane — both aim to bring cloud resource management into the Kubernetes world.

While they share similar goals and some overlapping features, this post is focused on ASO v2. I won’t dive into a full comparison here — but stay tuned! I’ll be sharing a dedicated post soon that explores Crossplane in more depth, along with a detailed side-by-side breakdown.

For now, just know that these tools aren’t necessarily competing — they can be complementary, depending on your cloud strategy and team structure.

Final thoughts

GitOps and Kubernetes have changed how we manage modern applications. With Azure Service Operator v2, you can bring those same practices to your infrastructure — making Azure resources part of your Kubernetes-native, declarative workflows.

Whether it’s provisioning databases, Key Vaults, or storage accounts, ASO v2 helps you build secure, consistent, and repeatable environments — all from YAML.

That said, tools like Terraform and Bicep aren’t going away. A hybrid approach is a good option:

Platform teams use Terraform/Bicep to set up baseline infrastructure.
Developers use ASO v2 / Crossplane to provision and manage app-specific resources, backed by GitOps.

This way, you get the stability of traditional IaC and the flexibility of Kubernetes-native workflows.

Microsoft is continuing to invest in ASO, and it’s already proving to be a powerful tool for hybrid and cloud-native teams alike.