Azure Service Operator v2 reached general availability in October 2022. It enables management of Azure resources using Kubernetes custom resources and GitOps workflows, integrating Azure infrastructure into the Kubernetes-native operations model.
What Azure Service Operator enables
ASO v2 lets you define Azure resources (Storage accounts, Azure SQL databases, Event Hubs, Service Bus namespaces) as Kubernetes custom resources in YAML manifests. Applying those manifests to your cluster provisions the corresponding Azure resources. Deleting the manifest deletes the Azure resource. The Azure control plane becomes an extension of your Kubernetes control plane.
The GitOps workflow integration
When combined with Flux or Argo CD, ASO v2 means your Azure infrastructure is managed the same way as your application workloads: changes go through a Git pull request, are reviewed, merged, and then applied to the cluster by the GitOps operator. The Azure resource provisioning history is in your Git log. Rollback is a git revert.
Managed identity for resource access
Resources provisioned by ASO can be configured to use managed identities. An Azure SQL database provisioned by ASO can have a managed identity credential that the application's Kubernetes service account is authorised to use, without storing a connection string anywhere. The full stack, from resource provisioning to credential management to application access, can be managed through Kubernetes.
When to use vs Bicep or Terraform
ASO makes sense when you are already operating a Kubernetes cluster and want to manage Azure resources in the same workflow. For teams that are not running Kubernetes, Bicep or Terraform provide a simpler path to Azure infrastructure management. The decision is architectural: Kubernetes-first teams get value from ASO; infrastructure-first teams get less value from adding a Kubernetes dependency.