Microsoft Fabric: CI/CD Pipeline Authentication (Workload Identity Federation)
Context
In this post I am going to talk about the authentication method Workload Identity Federation for CI/CD pipelines with focus on Azure DevOps and Microsoft Fabric.
If you already built a CI/CD pipeline, you probably started with a Service Principal and a client secret. It works, but then you have to store that secret somewhere and someone has to rotate it before it expires. With Workload Identity Federation (WIF) we don't have this problem anymore.
The purpose of this post is to show you the concept and the architecture behind it. There is no YAML pipeline code here, this is maybe a topic for another blog post :)
In this post we are going to talk about the following topics:
Secret based approach vs. Workload Identity Federation
Which components you need
Why we use an Azure Resource Manager service connection
How to create the service connection in Azure DevOps
How to create the federated credential in Microsoft Entra ID
Secret based approach vs. Workload Identity Federation
In the classic approach you authenticate with a Service Principal and a client secret. The secret has to be stored in a vault (for example Azure Key Vault, HashiCorp Vault), fetched during the pipeline run and rotated before it expires. See below the diagram as an example for deploying something in Microsoft Fabric.
With Workload Identity Federation you create a trust between Azure DevOps and Microsoft Entra ID using OpenID Connect (OIDC). The pipeline gets a token at runtime and exchanges it for an Entra ID token. The big advantage here is that you don't need to manage secrets anymore. See below the diagram:
It would be too much to explain what is happening under the hood, but this part is very well documented by Microsoft here or the YouTube video from John Savill. So, there is no point of repeating it in this post.
The rest of the architecture stays the same in both approaches. The Service Principal is a member of a security group, the security group gets the Fabric API permissions and the Service Principal gets access to the Fabric workspace.
Which components do you need?
Entra Application (Service Principal) per environment, for example dev, qual and prod. Like this every environment has its own identity and its own permissions.
Entra ID security group with these Service Principals as members. This group needs to get the Fabric API permission in the Admin portal from Fabric to allow using the Fabric REST APIs.
Each Service Principal must be a member of the Fabric workspace, with the role that your pipeline needs (e.g. Member role in the workspace).
Azure DevOps service connection per environment, for example sc-fabric-cicd-dev, sc-fabric-cicd-qual and sc-fabric-cicd-prod.
See below the service connections in Azure DevOps:
Why do we use Azure Resource Manager as service connection type?
This is the part that confused me in the beginning. There is no service connection type for Microsoft Fabric in Azure DevOps.
So, we use the Azure Resource Manager service connection as a workaround. We are not deploying Azure resources with it. We only use it to get the federated token for our Service Principal, which we then use against the Fabric REST APIs. But, yes there is a but, the person creating the service connection needs at least read permission on an Azure subscription, because the Azure Resource Manager service connection is scoped to an Azure subscription. Ok, now with everything set up, let’s begin with the implementation :)
Step 1: Create the service connection in Azure DevOps
Go to Project settings > Service connections > New service connection and choose Azure Resource Manager:
Then select the following:
Identity type: App registration or managed identity (manual). I use the manual option because normally people are not allowed to create Entra Application, so you might need to ask someone responsible for your Azure tenant
Credential: Workload identity federation
Service connection name: use a naming convention per environment, for example sc-fabric-cicd-dev
Directory (tenant) ID: your Microsoft Entra ID tenant (you can find this on the overview page of your app registration in Azure)
In the next step Azure DevOps generates two values that you need later on the Azure side, the Issuer and the Subject identifier. Copy both of them, we will use them later :)
Here you also select the Scope Level (Subscription) and fill in the Subscription ID and Subscription name. This is the part where you need the subscription access mentioned above. The Application (client) ID is the App registration that we configure in the next step.
Now you can save the service connection as draft. It stays in draft until the federated credential exists in Azure.
Step 2: Create the federated credential
Go to your App registration in the Azure portal and then to Certificates & secrets > Federated credentials > Add credential.
You can see the tabs Certificates, Client secrets and Federated credentials. We are not creating anything under Client secrets, this is exactly the point of this approach :)
In the “Add a credential” blade fill in the following below:
Federated credential scenario: Other issuer
Issuer: the Issuer from the Azure DevOps service connection
Type: Explicit subject identifier
Value: the Subject identifier from the Azure DevOps service connection
Name: a name that you recognize, for example the name of the service connection
Audience: leave the default api://AzureADTokenExchange
The Issuer and the Subject identifier are the values that create the trust. Azure DevOps guarantees that only this service connection uses this subject identifier, so no other project or pipeline can use your Service Principal.
Step 3: Verify and save
Go back to the service connection in Azure DevOps and click on Verify and save. If the federated credential matches, the service connection is not in draft anymore and you can use it.
One thing that I always forget: the service connection cannot be used in a YAML pipeline until at least one pipeline has permission for it. Open the service connection, go to Security > Pipeline permissions and add the pipeline that should use this connection.
I would also not check the option "Grant access permission to all pipelines", especially for the production service connection.
Conclusion
In this post we talked about Workload Identity Federation as authentication method for Fabric CI/CD pipelines with Azure DevOps. The main advantage is that you don't need to manage and rotate secrets anymore.
The two things I would keep in mind are that there is still no service connection type for Microsoft Fabric, so we use Azure Resource Manager as a workaround, and that you need at least read permission on an Azure subscription to create it.
Last updated on August 10, 2026