Microsoft Azure
Last updated
Was this helpful?
Last updated
Was this helpful?
Spacelift provides support for managing Azure resources via the Terraform . The documentation for the Azure Provider outlines the different authentication methods it supports, and it should always be considered the ultimate source of truth.
This page explains how to configure the following authentication methods in Spacelift:
- the simplest way to get up and running. Handles automatic secret creation and rotation, but is only supported on public workers.
- useful when using the public worker pool, or workers that are not hosted in Azure. Simple to setup, but requires you to manually manage secret rotation.
- ideal when using hosted in Azure. Requires managing your own workers, but secret rotation is handled automatically by Azure.
The Spacelift managed integration is great for situations where you want to get up and running quickly, and where you want the reassurance that the credentials for accessing your Azure account will be automatically rotated and stored securely. If you are not comfortable with Spacelift managing your Azure credentials, we would suggest that you use a private worker configured with a for the most control and security.
When an Azure integration is created, an associated Azure AD Application is created within Azure. We automatically create a client secret for that application, and rotate it roughly once every 24 hours. The secret is stored securely, encrypted using AWS .
To add a new integration, go to the Azure page under your account settings. When you go there for the first time, the page will be empty, but will prompt you to add an integration:
Click on the Add Integration button to start configuring your integration:
Give your integration a name, and enter your Active Directory Tenant ID. You can also enter a default subscription ID at this point. You can specify the default subscription ID if you want to attach your integration to multiple stacks that are all going to use the same Azure subscription.
Once your integration has been created successfully, you will be taken to the integration details. It should look something like this:
To install the Azure AD application for your Spacelift integration into your Azure account, click on the Provide Consent button, which will redirect you to Azure. After logging into your Azure account, you should see a permissions screen like the following:
Click on the Accept button to complete the admin consent process, at which point you should be redirected to your integration settings.
Azure AD uses eventual consistency to replicate new Azure applications globally. Because of this you might see the following error message if you try to grant admin consent very quickly after the integration was created:
This isn’t a problem. Just wait a few minutes and try again.
If you go to the Access Control (IAM) section of the Azure subscription or resource group you want the integration to have access to, you should be able to add a new role assignment for the integration:
To attach an integration to a Stack, edit the Integrations settings for your stack, and choose the Azure option from the list:
Choose the integration you want to attach, specify a subscription ID if the integration you’ve chosen doesn’t have a default or you want to override the default, and specify whether the integration should be used for read, write or read and write operations:
Click on the Attach button to add the integration to your stack.
If you want to detach an integration from a stack, just click the Detach button next to the integration:
You can delete an Azure integration if you don’t need it anymore. To do that, go to the Azure Integrations settings screen, and click the Delete button next to the integration you want to remove:
Deleting the integration does not remove the Enterprise Application that was added to your Azure AD account via the admin consent process. You need to do that yourself manually after deleting the integration.
To use static credentials, you need to create an Azure Service Principal, grant it access to your Azure subscription, and then configure the Azure Provider to use the Service Principal via environment variables.
Create a Service Principal using the following command, substituting<subscription-id> with your own subscription ID:
This will output something like the following:
The command creates a new Service Principal called spacelift-sp, and grants it the Contributor role on your subscription. It also outputs the appId, password and tenant for the Service Principal. Make a note of these because you'll need them later.
Azure provides two options for authenticating Service Principals:
Client secrets - a randomly generated string.
Client certificates - an x509 certificate.
Either option can be used depending on your requirements, and the configuration required for both is very similar.
ARM_CLIENT_ID - the appId returned when you created your Service Principal. This is known as the Application ID or Client ID within Azure.
ARM_CLIENT_SECRET - the password returned when you created your Service Principal.
ARM_SUBSCRIPTION_ID - your subscription ID.
ARM_TENANT_ID - the tenant returned when you created your Service Principal.
Once finished, your environment should look something like this:
You should treat this certificate like any other credential, and mark it as a secret.
ARM_CLIENT_ID - the appId returned when you created your Service Principal. This is known as the Application ID or Client ID within Azure.
ARM_CLIENT_CERTIFICATE_PATH - the path to the certificate you uploaded in the previous step.
ARM_CLIENT_CERTIFICATE_PASSWORD - the password for your certificate.
ARM_SUBSCRIPTION_ID - your subscription ID.
ARM_TENANT_ID - the tenant returned when you created your Service Principal.
Once finished, your environment should look something like this:
When using static credentials, you are in charge of managing credential rotation. When using the az ad sp create-for-rbac command, the client secret returned by the command will expire in 1 year. At that point, any stacks using that client secret will stop working until a new one is added and the Spacelift environment updated.
To use a managed identity, you need to take the following steps:
Create an Azure VM with a managed identity, and install the worker binary on it.
To configure the Azure provider to use the managed identity, add the following environment variables to your stack:
ARM_USE_MSI - set to true to indicate you want to use a managed identity.
ARM_SUBSCRIPTION_ID - your subscription ID.
ARM_TENANT_ID - your Azure AD tenant.
In addition, if using a user-assigned identity, add the following variable to your stack:
ARM_CLIENT_ID - the client ID of your user-assigned identity.
Once finished, your environment should look something like this:
You can find your Tenant ID by going to the section of the Azure portal. You can also find your Azure subscriptions by going to the section of the Azure portal.
Now that you have granted admin consent, a new Enterprise Application will be created for your integration in Azure. You can view this in the section of Azure Active Directory:
If you already understand how to create and manage Service Principals, feel free to skip to the section.
To configure the Azure provider using a client secret, add the following to your stack:
To configure the Azure provider using a client certificate, first add your PFX as a to your environment:
Next, add the following to your stack:
Azure allow you to assign an identity to an Azure virtual machine, and then use that identity for role assignment. This means that you can grant your Spacelift private workers permission to manage your Azure resources,without having to store any credentials in Spacelift, or deal with credential rotation.
Follow the to setup a private worker pool.
Configure the to use the managed identity for authentication.
