Skip to content

Announcing Enhanced VCS Integration ๐ŸŽ‰ ๐ŸŽ‰

Read more here โ†’

Microsoft Azureยป

Configuring workload identity federationยป

In order to enable Spacelift runs to access Azure resources, you need to set up Spacelift as a valid identity provider for your account. This is done using workload identity federation. The set up process involves creating an App Registration, and then adding federated credentials that tell Azure which Spacelift runs should be able to use which App Registrations. This process can be completed via the Azure Portal, Azure CLI or Terraform. For illustrative purposes we will use the Azure Portal.


Note that the following instructions show how to setup federation using a Microsoft Entra App, but the same approach can also be used with a user-assigned managed identity.

The first step is to go to the Azure AD section of the Azure Portal, go to App registrations, and then click on the New registration button:

New registration

Specify a name for your registration, select the Accounts in this organizational directory only option, and click on the Register button:


On the overview page, take a note of the Application (client) ID and Directory (tenant) ID - you will need them later when configuring the Terraform provider.

App registration overview

Next, go to the Certificates & secrets section, select the Federated credentials tab and click on the Add credential button:

Add credential

On the next screen, choose Other issuer as the Federated credential scenario:

Other issuer

The next step is to configure the trust relationship between Spacelift and Azure. In order to do this, we need to fill out the following pieces of information:

  • Issuer - the URL of your Spacelift account, for example
  • Subject identifier - the subject that a token must contain to be able to get credentials for your App. This uses the format mentioned in the Standard claims section.
  • Name - a name for this credential.
  • Audience - the hostname of your Spacelift account, for example

Take a look at the following screenshot for an example allowing a proposed run to use our App:

Proposed run reader

Workload federation in Azure requires the subject claim of the OIDC token to exactly match the federated credential, and doesn't allow wildcards. Because of this you will need to repeat the same process and add a number of different federated credentials in order to support all the different types of runs for your Stack or module. For example for a stack called azure-oidc-test in the legacy space you need to add credentials for the following subjects:


And for a module called my-module in the development space you need to add the following:


After adding all the credentials for a stack, it should look something like this:

Stack credentials added


Please see the Standard claims section for more information about the subject format.

Configuring the Terraform Providerยป

Once workload identity federation is set up, the AzureRM provider can be configured without the need for any static credentials. To do this, enable the use_oidc feature of the provider, and use the oidc_token_file_path setting to tell the provider where to find the token:

provider "azurerm" {
  features {}
  use_oidc             = true
  oidc_token_file_path = "/mnt/workspace/spacelift.oidc"

Next, add the following environment variables to your stack:

  • ARM_CLIENT_ID - the client ID of the App registration created in the previous section.
  • ARM_TENANT_ID - the tenant ID of the App registration created in the previous section.
  • ARM_SUBSCRIPTION_ID - the ID of the Azure subscription you want to use.


Note - before you can use your App registration to manage Azure resources, you need to assign the correct RBAC permissions to it.