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.

Info

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:

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.

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

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

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 https://myaccount.app.spacelift.io.
• 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 myaccount.app.spacelift.io.

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

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:

space:legacy:stack:azure-oidc-test:run_type:TRACKED:scope:read
space:legacy:stack:azure-oidc-test:run_type:TRACKED:scope:write
space:legacy:stack:azure-oidc-test:run_type:PROPOSED:scope:read
space:legacy:stack:azure-oidc-test:run_type:TASK:scope:write
space:legacy:stack:azure-oidc-test:run_type:DESTROY:scope:write

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

space:development:stack:my-module:run_type:TESTING:scope:read
space:development:stack:my-module:run_type:TESTING:scope:write

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

Info

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.

Info

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