Orchestrating Azure Infrastructure through Terraform and GitHub Actions

The intersection of Infrastructure as Code (IaC) and Continuous Integration and Continuous Deployment (CI/CD) represents the pinnacle of modern cloud engineering. By leveraging Terraform as the provisioning engine and GitHub Actions as the orchestration layer, organizations can transform their Azure environment into a programmable, version-controlled entity. This synergy allows for the elimination of manual intervention in the Azure Portal, reducing human error and ensuring that the desired state of the cloud environment is always mirrored in the source code. The integration of these tools creates a robust pipeline where every change to the infrastructure is vetted through automated testing, security scanning, and peer review before being applied to the live environment.

The fundamental architecture of this integration relies on a sophisticated workflow that mirrors the software development lifecycle. When a developer proposes a change to the Azure infrastructure—such as deploying an Azure Kubernetes Service (AKS) cluster—they do not apply the changes directly. Instead, they commit the Terraform code to a feature branch and open a Pull Request (PR). This act triggers a series of automated checks: linting via terraform fmt to ensure style consistency, validation via terraform validate to verify syntactic correctness, and security analysis via tools like Checkov or TFSEC to identify vulnerabilities. The culmination of the PR process is the generation of a Terraform plan, which serves as a blueprint of the exact modifications that will occur. This "dry run" is critical for operational stability, as it allows engineers to preview the impact of their changes—such as whether a resource will be updated in place or destroyed and recreated—before any actual modifications are executed in the Azure subscription.

Once the Pull Request is approved and merged into the main branch, the orchestration shifts from validation to execution. A separate GitHub Actions workflow triggers, utilizing the approved code to apply the changes to the Azure environment. To ensure the long-term health of the infrastructure, a scheduled workflow is implemented to detect configuration drift. Drift occurs when manual changes are made to the Azure resources outside of the Terraform workflow, creating a discrepancy between the state file and the actual environment. By automating the detection of this drift and generating GitHub issues when inconsistencies are found, the system maintains a strict "source of truth" within the Git repository.

Security and Authentication via OpenID Connect (OIDC)

The traditional method of authentic Vodafone credentials in GitHub Actions involved storing long-lived Service Principal client secrets as GitHub Secrets. This approach presented significant security risks, as secrets could potentially be leaked or required manual rotation. The modern standard shifts toward OpenID Connect (OIDC), a federated identity protocol that allows GitHub Actions to request short-lived access tokens directly from Microsoft Entra ID (formerly Azure Active Directory).

OIDC functions by establishing a trust relationship between Microsoft Entra ID and GitHub. When a workflow runs, GitHub provides a JWT (JSON Web Token) to Azure, which Azure then verifies against a pre-configured federated credential. If the token is valid and the workflow meets the defined conditions, Azure issues a temporary access token. The impact of this transition is profound: it eliminates the need for static secrets, reduces the attack surface for credential theft, and allows for more granular control over which specific GitHub branches or environments can request tokens.

To implement this, an Azure Active Directory application must be created with the necessary read/write permissions for the target Azure subscription. The setup process involves configuring federated credentials that map the GitHub repository, branch, or environment to the Azure identity. This ensures that only authorized workflows can interact with the Azure API.

Terraform Provider Configuration for Azure and OIDC

To successfully utilize OIDC within a GitHub Actions environment, the Terraform configuration must be explicitly told to use this authentication method. This is handled within the providers.tf file, where the backend and the providers are defined.

The following configuration demonstrates the requirement for OIDC enablement across the AzureRM and AzAPI providers:

```hcl
terraform {
requiredversion = ">=1.0"
requiredproviders {
azurerm = {
source = "hashicorp/azurerm"
version = "~>3.0"
}
azapi = {
source = "azure/azapi"
version = "~>1.5"
}
random = {
source = "hashicorp/random"
version = "~>3.0"
}
azuread = {
source = "hashicorp/azuread"
version = "2.30.0"
}
}
backend "azurerm" {
key = "terraform.tfstate"
use_oidc = true
}
}

provider "azurerm" {
features {}
use_oidc = true
}

provider "azapi" {
use_oidc = true
}
```

In this setup, the use_oidc = true flag is essential. In the backend "azurerm" block, this flag instructs Terraform to use the OIDC token to authenticate against the Azure Storage account where the state file is stored. Similarly, for the azurerm and azapi providers, this flag ensures that all API calls to Azure are authenticated via the short-lived token provided by GitHub Actions. The use of the AzAPI provider allows for the management of Azure resources that may not yet be fully supported by the primary AzureRM provider, offering a bridge to the latest Azure features.

The Automated Validation Pipeline

The initial phase of the deployment pipeline is focused on code quality and security. This phase is triggered upon every commit to a branch and is designed to fail fast, preventing subpar code from ever reaching the review stage.

The pipeline consists of several critical layers:

• Formatting: The terraform fmt command is executed to ensure that the code adheres to the standard HCL (HashiCorp Configuration Language) style. This prevents "noise" in Pull Requests where changes appear to be significant but are actually just formatting adjustments.
• Validation: The terraform validate command is used to check the syntax of the configuration files. It ensures that the code is internally consistent and that all required arguments for resources are provided.
• Security Scanning: Tools like Checkov or TFSEC are integrated to perform static code analysis (SCA). These tools scan the IaC templates for security misconfigurations, such as open SSH ports or unencrypted storage accounts, ensuring that the infrastructure is secure by design.
• Planning: A terraform plan is executed to generate a preview of the changes. This output is often posted as a comment on the Pull Request via the github_token (specifically ${{ secrets.GITHUB_TOKEN }}), providing reviewers with immediate visibility into the infrastructure impact.

Advanced Workflow Orchestration and Environment Management

For enterprise-grade deployments, GitHub Actions utilizes "Environments" to introduce a layer of human governance and safety. By creating a dedicated environment, such as one named production, administrators can implement protection rules.

These protection rules include:

• Required Reviewers: The workflow is paused until a designated individual or team manually approves the deployment. This prevents accidental pushes to production.
• Branch Restrictions: The production environment can be restricted so that only code merged into the main branch can trigger a deployment, ensuring that all changes have passed the PR process.
• Secret Isolation: Environment-specific secrets can be stored, ensuring that development credentials are never used in production.

The workflow typically separates the "Plan" and "Apply" stages into different jobs. This separation allows the "Apply" job to depend on the successful completion of the "Plan" job and the manual approval of the environment.

Technical Implementation of the Terraform Plan Action

The Pwd9000-ML/terraform-azurerm-plan action provides a streamlined way to handle the planning phase within the GitHub ecosystem. This action connects to the remote Azure backend and uploads the resulting plan as a workflow artifact, which can then be used by a subsequent "Apply" action.

The action requires specific inputs to function correctly, as detailed in the following table:

The implementation of this action in a YAML workflow follows this structure:

yaml - name: Dev TF Plan uses: Pwd9000-ML/[email protected] with: path: "path-to-TFmodule" plan_mode: "deploy" tf_version: "latest" tf_vars_file: "tfvars-file-name" tf_key: "state-file-name" enable_TFSEC: true

It is important to note that this specific action currently only supports Linux runners, specifically those labeled ubuntu-latest or ubuntu-20-04 and ubuntu-18.04.

Data Sources and Resource Referencing

Within the Terraform code used by these workflows, the use of data blocks is critical for creating dynamic and reusable configurations. A data block allows Terraform to fetch information from an existing Azure resource without needing to manage that resource.

For example, using the azurerm_subscription data source allows the practitioner to retrieve the current subscription details. This is particularly useful for role assignments. The data block requests information from the Azure API and exports it under a local name, such as sub. This allows other parts of the configuration to reference the subscription ID using the syntax data.azurerm_subscription.sub.id. This method ensures that the code remains portable across different Azure subscriptions without needing to hardcode IDs.

Infrastructure Drift Detection and Resolution

A unique and critical component of the Terraform-Azure-GitHub integration is the scheduled drift detection workflow. While the CI/CD pipeline ensures that changes are applied correctly, "drift" occurs when an administrator makes a manual change via the Azure Portal or CLI, bypassing the Git-based workflow.

The drift detection process involves:

• Scheduling: A GitHub Action is configured to run on a cron schedule (e.g., daily).
• Comparison: The workflow runs a terraform plan against the live environment.
• Detection: If the plan indicates that changes are required to bring the environment back to the state defined in the code, drift has occurred.
• Notification: The workflow is configured to create a new GitHub issue automatically when drift is detected.

This cycle forces the team to either revert the manual change in the portal or update the Terraform code to reflect the new reality, ensuring that the Git repository remains the absolute source of truth for the infrastructure.

Conclusion

The integration of Terraform and GitHub Actions for Azure infrastructure management transforms the process of cloud deployment from a manual, error-prone task into a disciplined software engineering practice. By implementing OIDC, organizations eliminate the vulnerabilities associated with long-lived secrets, while the use of a multi-stage pipeline—comprising formatting, validation, security scanning, and peer-reviewed planning—ensures that only high-quality, secure code is deployed. The addition of environment-based approvals and automated drift detection completes the lifecycle, providing a comprehensive framework that supports both the speed of development and the stability of production. This architecture not only accelerates the deployment of complex resources like Azure Kubernetes Service but also establishes a scalable foundation for any cloud-native infrastructure.

Sources

1. GitHub - terraform-github-actions
2. Will Velida - GitHub Actions Terraform Azure
3. Microsoft Learn - IaC GitHub Actions
4. Dev.to - Deploying to Azure with Terraform and GitHub Actions
5. GitHub Marketplace - Terraform Plan for Azure