In the past, managing infrastructure meant manually applying changes, which often led to configuration drift. Configuration drift happens when the actual state of your environment (what is running in Azure) is different from the desired state (what is defined in your code repository). This drift is a major cause of instability, security issues, and deployment failures in complex scenario’s.

To overcome configuration drift, the industry has widely adopted the GitOps methodology. GitOps uses Git as the single source of truth for both your applications and your infrastructure. Instead of manually applying changes to your environment, you only modify your Git repository. An automated process then ensures that your live environment always matches the code in Git. This makes your infrastructure changes traceable, verifiable, and automatically reversible.

This article will guide you through setting up a powerful GitOps environment on Azure by combining two leading open-source tools: Terraform for defining the infrastructure (the Azure resources) and FluxCD for continuously syncing that infrastructure. We will focus on how this combination prevents configuration drift by making sure your Azure environment is continuously checked and reconciled against your Git repository. By the end of this article, you will have a robust pipeline where any unauthorized change made directly in Azure will be automatically undone, enforcing your desired state.

Configuration drift is the enemy of stability. When an engineer manually changes a setting on an Azure resource (for example, scaling an AKS cluster through the portal instead of through code), the environment becomes non-compliant. GitOps solves this by creating a reconciliation loop.

By integrating FluxCD to manage the application of your Terraform outputs, you create a system where the running infrastructure is constantly validated against the configuration stored in Git, minimizing the chance of drift and making your entire deployment process much more reliable.

For a reliable, enterprise-ready GitOps solution, just installing the tools is not enough. You must adhere to architectural best practices. This section outlines key design decisions in the GitOps world, explaining the approach used in this article with alternatives.

The most foundational design choice in GitOps is how changes are applied to the cluster:

How you organize your code repository affects scalability and security.

While we use FluxCD and the FluxCD Terraform Controller, there are alternative open-source tools that achieve similar goals:

The Terraform Controller needs permissions to modify Azure resources. It is a best practice to use a dedicated Service Principal or Managed Identity with the minimum required permissions (Least Privilege). This limits the “blast radius” if the controller is ever compromised. We will use a Managed Identity in this article.

It is now time to guide you through setting up the Azure resources, connecting your local environment, and installing the necessary command-line tools.

Before diving into the next steps, ensure you have the following prerequisites in place:

In this step, we provision the Azure resources and prepare the Git repository that will hold our desired state.

az login

RESOURCE_GROUP="rg-gitops-flux"
LOCATION="westeurope"
CLUSTER_NAME="aks-gitops-tf"

# Create Resource Group
az group create --name $RESOURCE_GROUP --location $LOCATION

# Deploy a basic AKS cluster with 3 nodes and Managed Identity
az aks create \
  --resource-group $RESOURCE_GROUP \
  --name $CLUSTER_NAME \
  --node-count 3 \
  --node-vm-size Standard_D2S_v3 \
  --enable-managed-identity \
  --generate-ssh-keys 

# Get Kubernetes credentials and ensure the kubeconfig is fresh
az aks get-credentials --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --overwrite-existing

mkdir fluxcd-terraform-gitops
cd fluxcd-terraform-gitops
git init

# Create the required folder structure
mkdir infrastructure
mkdir clusters

We now define the desired state for our AKS node pool, focusing on the minimum node count of 3 which we want to enforce as a drift guardrail.

Get the unique ID that is necessary for the Terraform-file.

CLUSTER_ID=$(az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query id -o tsv)
echo "Using Cluster ID: $CLUSTER_ID"

Create the file infrastructure/main.tf. Paste the cluster ID in this file.

resource "azurerm_kubernetes_cluster_node_pool" "core_pool" {
  name                  = "corepool"
  kubernetes_cluster_id = "${CLUSTER_ID}"        # Paste your Cluster ID here
  vm_size               = "Standard_D2S_v3"
  node_count            = 3
  min_count             = 3                      # Desired state guardrail
  max_count             = 5
  enable_auto_scaling   = true
}

# This data block is required for the Terraform Controller
data "azurerm_client_config" "current" {}

Connect your local repository with your remote GitHub repository and push the initial files. Replace the placeholders with your own values.

git add .
git commit -m "feat: Initial AKS node pool configuration with min_count=3"
git remote add origin https://github.com/azurebeastcom/fluxcd-terraform-gitops.git
git push -u origin main

This is the important step to install the GitOps-agent and the Terraform Controller. We’ll use the most reliable HTTPS/PAT-method to bypass SSH issues.

Set your personal GitHub username and PAT as an environment variable.

# Replace [YOUR_PERSONAL_USERNAME] and [YOUR_PAT_TOKEN] with your own values
export GITHUB_USER="[YOUR_PERSONAL_USERNAME]"
export GITHUB_PAT="[YOUR_PAT_TOKEN]" 

Install the Flux-components on the AKS-cluster and configure the Git-connection. Make sure to replace the placeholders with your own values.

flux bootstrap git \
  --url https://github.com/azurebeastcom/fluxcd-terraform-gitops.git \
  --branch main \
  --path ./clusters \
  --username "$GITHUB_USER" \
  --password "$GITHUB_PAT"

ℹ️ Info: This command may freeze sometimes. However, the components are now installed. Press Ctrl+C to return to the prompt.

The Flux-components will now try to clone through SSH, which will fail. We’ll have to patch this to use HTTPS/PAT. Patch the GitRepository URL to change the URL from SSH to HTTPS. Make sure to change the placeholders to your own values.

kubectl patch gitrepository flux-system -n flux-system --type=json \
  -p='[{"op": "replace", "path": "/spec/url", "value": "https://github.com/azurebeastcom/fluxcd-terraform-gitops.git"}]'

We’ll inject the username and PAT into the secret.

kubectl patch secret flux-system -n flux-system --type=merge -p "
{\"data\": {
  \"username\": \"$(echo -n $GITHUB_USER | base64)\", 
  \"password\": \"$(echo -n $GITHUB_PAT | base64)\"
}}
"

Verify if the Flux Source Controller can succesfully clone the repository using the new HTTPS-settings.

kubectl get gitrepository -n flux-system flux-system

Wait till the READY-status is set to True and the STATUS-notification confirms that the revision has been pulled. It should look like the example below.

Create the clusters/terraform-cr.yaml file. This file will tell the Terraform Controller what it should apply and how to authenticate.

apiVersion: infra.contrib.fluxcd.io/v1alpha2
kind: Terraform
metadata:
  name: aks-drift-reconciler
  namespace: flux-system
spec:
  interval: 5m # Check for drift every 5 minutes
  path: ./infrastructure
  approvePlan: "auto" # Automatically apply changes when drift is found

  # The source code repository
  sourceRef:
    kind: GitRepository
    name: flux-system

  # Authentication using AKS Managed Identity (recommended Best Practice)
  runnerPodTemplate:
    spec:
      serviceAccountName: default 
      containers:
        - name: runner
          env:
            - name: ARM_USE_MSI
              value: "true"

Create the Flux Kustomization file clusters/kustimozation.yaml. This is the configuration that will tell Flux to apply the Terraform Custom Resource (CRD).

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: aks-drift-enforcement
  namespace: flux-system
spec:
  interval: 10m0s
  path: ./
  prune: true
  sourceRef:
    kind: GitRepository
    name: flux-system
  targetNamespace: flux-system
  # Reference the Terraform manifest to apply it
  resources:
    - ./terraform-cr.yaml 

Push the configuration files to GitHub. The Flux Kustomize Controller will see the changes within a matter of minutes.

git add clusters/
git commit -m "feat: Add Flux Kustomization and Terraform CRD"
git push

The Kustomize Controller will detect the new files, apply the terraform-cr.yaml, and the Terraform Controller will start to enforce the main.tf code.

Check if the terraform-controller pod was started. This may take a while.

kubectl get pods -n flux-system

Wait till the terraform-controller pod appears and has a Running state.

The Terraform Controller will now execute its first terraform plan and terraform apply to match the state in Azure with the Git-code (min_count=3).

kubectl get terraform -n flux-system aks-drift-reconciler

Wait till the state has changed to Applied. This confirms that the IaC has been executed.

Go to the Azure Portal. Navigate to your AKS Cluster. Under Node Pools, find corepool. Manually change the Minimum node count from 3 to 1 and apply this change.

Wait for about 5 minutes (interval: 5m). The Terraform Controller will detect the drift. Check the status to see how the correction will look like.```

kubectl get terraform -n flux-system aks-drift-reconciler

The status will briefly change and return to Applied once the minimum node count in Azure is corrected to 3, solving the drift.

By combining the declarative power of Terraform for infrastructure definition with the continuous reconciliation capability of FluxCD, you have successfully implemented a robust GitOps model on Azure. You have moved beyond simply deploying infrastructure from Git; you now have an active control plane that automatically detects and corrects any manual deviations or configuration drift on your AKS cluster. This approach ensures your production environment always mirrors your code, improving stability, auditability, and reliability.

To learn more about GitOps and how it can benefit your specific scenarios, I recommend exploring the following resources:

Thank you for taking the time to go through this post and making it to the end. Stay tuned, because we’ll keep continuing providing more content on topics like this in the future.