# October 29, 2025

## Pipelines

### Azure OIDC and Custom Auth for Pipelines

Gruntwork Pipelines now supports native configuration of authentication to Azure. In addition we’re providing a built-in mechanism to execute custom scripts to provide authentication credentials for Terragrunt executions. This change makes it easy to use Gruntwork Pipelines with any of your preferred cloud providers.

**Native Azure Authentication Support**

We’ve introduced an `azure_oidc` [block](https://docs.gruntwork.io/2.0/reference/pipelines/configurations-as-code/api#azure_oidc-block-attributes) inside the Gruntwork HCL configuration as code specification. This block requires that you specify your `tenant_id` and `subscription_id` as well as a `client_id` for plans and applies. For example:

```hcl
# my_azure_environment.hcl

environment "my_azure_subscription" {
  filter {
    paths = ["my-azure-subscription/*"]
  }

authentication {
    azure_oidc {
      tenant_id       = "a-tenant-id"
      subscription_id = "a-subscription-id"
      plan_client_id  = "plan-client-id"
      apply_client_id = "apply-client-id"
    }
  }
}
```

**Custom Authentication Scripts**

Within any given environment, you can also now specify a `custom` [block](https://docs.gruntwork.io/2.0/reference/pipelines/configurations-as-code/api#custom-block-attributes) with a `auth_provider_cmd`. The provided command will be executed prior to every Terragrunt invocation and can return/inject values into the environment for Terragrunt and ultimately your OpenTofu/Terraform code. This is useful if, for example, you want to fetch secrets from a vault before running, or run a custom OIDC flow for a cloud provider that doesn’t yet have built-in support with pipelines. We’ve published a [page](https://docs.gruntwork.io/2.0/docs/pipelines/concepts/cloud-auth/custom/) covering several examples of how to use this new capability. Here’s an example:

```hcl
# my_cloudflare_environment.hcl

environment "cloudflare_environment" {
  filter {
    paths = ["cloudflare/*"]
  }

authentication {
    custom {
      auth_provider_cmd = "./scripts/cloudflare-auth.sh"
    }
  }
}
```

```hcl
# cloudflare-auth.sh

#!/bin/bash
set -e

# Acquire a Cloudflare API token
# This is just an example of how to acquire a Cloudflare API token from a secrets manager.
# You can use any method you like to set environment variables like this,
# but you are encouraged never to hardcode secrets in your repository.
CLOUDFLARE_API_TOKEN=$(aws secretsmanager get-secret-value --secret-id cloudflare-api-token --query SecretString --output text)

# Output credentials in the format expected by Terragrunt
cat <<EOF
{
  "envs": {
    "CLOUDFLARE_API_TOKEN": "$CLOUDFLARE_API_TOKEN",
  }
}
EOF
```

**How to Upgrade**

These new capabilities are available now with the [GitHub v4](https://github.com/gruntwork-io/pipelines-workflows/releases/tag/v4.0.0) and [GitLab v2](https://github.com/gruntwork-io/pipelines-gitlab-actions/releases/tag/v2.0.0) releases, which you can update to following our migration guides ( [GitHub guide](https://docs.gruntwork.io/2.0/docs/pipelines/previous-versions/upgrading-github-v3-to-v4)) ( [GitLab guide](https://docs.gruntwork.io/2.0/docs/pipelines/previous-versions/upgrading-gitlab-v1-to-v2)).