Managing multiple environments in multiple Azure subscriptions using Azure workload identity federation service connection with Azure Devops and Terraform
Streamline your terraform code to manage multiple environments in multiple azure subscriptions without the need of creating/storing/renewing the service principal secrets.🔥🚀
👋 Hey, Venki here! Welcome to another 🔓medium story 🔓. Each day I focus on 1 story that are making a difference to me when am working in the financial services technology space. Coupled with things worth learning & most important !! Get shit done. it’s the only publication (Urban DevOps) you need for all things when DevOps meets Cloud.
If you’re not a follower, Don’t miss out and join the community here pls👇🏼
First things first!!!! What the heck is workload identity ? why should i be bothered to even change my existing Azure Resource Manager service connection? 🤔or you could even say “ Am just a lazy devops person and just want to get my work done without any concern for infra security “….🦥
Change is inevitable!!! either we update ourselves on the relevant work by reading docs pertaining to the product we work on daily basis or we perish or become stale on the technology front.
Workload identity federation:
Workload Identity Federation is an OpenID Connect implementation for Azure DevOps that enables short-lived, credential-free authentication to Azure without needing self-hosted agents with managed identity. By configuring a trust between your Azure DevOps organization and an Azure service principal, Azure DevOps provides a token for authenticating to the Azure API.
Why use Workload identity federation
Previously, avoiding service principal secrets in Azure DevOps pipelines required self-hosted agents with managed identities. Now, with Workload Identity Federation, you can use short-lived tokens for Azure authentication, enhancing security and eliminating the need to manage secrets. This feature supports various Azure DevOps tasks, not just Terraform.
With the above definition and use of workload identity federation, Let’s get moving in how we put this to use in real world devops.😎😉
for those who are in fast lane reading or TL;DR or “ just show me the code man! “…code is in here 👉 EasyPeasy
Note: You will need an Azure Account with permissions to work with Microsoft Entra ID App registration, Azure Storage Account, Azure Keyvault and permissions to manage Azure Devops project, to create and manage service connections.
Steps to create Azure storage account to store terraform state files and Azure Keyvault to store secrets for Azure Subscription ID, Application ID and Tenant ID.
Using Azure CLI, execute the below to create a resource group, storage account, storage container and keyvault
#!/bin/bash
RESOURCE_GROUP_NAME=tfstatefdic2202
STORAGE_ACCOUNT_NAME=tfstate$RANDOM
KEYVAULT_NAME=tfkeyvault$RANDOM
CONTAINER_NAME=tfstate
# Create resource group
az group create --name $RESOURCE_GROUP_NAME --location eastus
# Create storage account
az storage account create --resource-group $RESOURCE_GROUP_NAME --name $STORAGE_ACCOUNT_NAME --sku Standard_LRS --encryption-services blob
# Create blob container
az storage container create --name $CONTAINER_NAME --account-name $STORAGE_ACCOUNT_NAME
# Create Key vault
az keyvault create --name $KEYVAULT_NAME --resource-group $RESOURCE_GROUP_NAME --enable-rbac-authorization
Steps to create Azure Resource Manager Workload Identity Federation Service Connection:
- Open Azure portal, go to Microsoft Entra ID and create a service principal via App Registration.
2. select your service principal and go to Certificate & secrets. Under the Federated credentials tab, press Add credential
3. in Azure DevOps, go to Service connections and create a new one selecting Azure Resource Manager
4. for the Authentication method, select Workload Identity federation (manual)
5. Provide the details as shown in the sample below
6. The Issuer and Subject Identifier will be needed at later stage to complete the FDIC setup as shown in pic with caption: FDIC
7. Go ahead and fill out the rest of the details to create the service connection, but do not hit the Verify and Save button yet. Instead, use the Keep Draft button to save the service connection as draft.
8. Add the Issuer and Subject identifier that we received while creating the Service connection in Azure devops. populate the details of those in the Add a credential step, which comes under App registration that we had followed in the earlier step.
If you have hit the Verify and Save button too early, you would receive the below message shown, since the App registration doesn’t find any resource associated with it yet in the Azure portal.
9. In Azure portal, We will add role assignments for App registration account that we had created to Storage Account and Key vault.
Grant Storage Blob Data Contributor role for App registration account on Storage Account.
You should now be able to find the role added to storage account as below.
10. Follow the same steps as above for Keyvault as well.
Grant Key Vault Secrets user role for App registration account on Key Vault.
Finally, you should be able to look at the role added.
11. Now that we have granted the required roles for App registration account, we can hit the Verify and Save button at the Service connection creation form / window. It should save without any errors.
Now that we have the necessary backend items for Terraform to function properly, let’s look at the terraform code for creating azure resource group in the next Part of this read…..since we had lot covered in this read and will take some time to digest it..😎
Until then Peace! ✌️✌️
Continue reading by following to Urban DevOps Publication stories. You will receive fresh contents about DevOps with hot takeaways every day.
***
About: I am DevOps enthusiast . My adventure in the tech world began over a decade ago. With a background in computer science, I started my career as a systems engineer. The thrill of building applications and solving complex problems captivated me, but I quickly realized that coding was just one piece of the puzzle. The real challenge — and reward — lay in ensuring that the software worked seamlessly in production, scaled effectively, and was robust against failures.
This realization led me to the world of DevOps. I immersed myself in the principles of continuous integration, continuous deployment, and infrastructure as code. The more I learned, the more I appreciated the profound impact DevOps practices could have on both development speed and operational reliability.
If you’ve enjoyed this piece, don’t hesitate to press clapping hands 👏, comment on what you think, and share the story with others 😀. Let’s spread the knowledge together!!
For more, hit the follow button and clap button🔥🚀
