This post shows how you can perform Fabric CI/CD securely in GitHub with OpenID Connect and fab deploy. As visualized below.

To clarify, OpenID Connect (OIDC) extends OAuth 2.0 to provide identity verification and allows GitHub Actions to securely authenticate to cloud providers using short-lived tokens instead of stored secrets.
Fab deploy is a new Fabric CLI command that allows you to use the fabric-cicd Python library directly within Fabric CLI in order to deploy Microsoft Fabric items into Microsoft Fabric workspaces. Without the need to install the additional fabric-cicd library. You still need fabric-cicd knowledge to work with it though.
This post contains an example based on a previous post where I covered how to use fab deploy in Azure DevOps. However, the OpenID Connect (OIDC) method enables secure CI/CD workflows across a variety of applications and services. Such as SQL Server and Azure App Service.
Security is a vital aspect when looking to perform CI/CD. The method shown in this post is secure due to the below reasons:
- Token is specific for Entra tenant.
- The OIDC token has a short lifespan.
- No need to expose subscription ID with this method.
- The solution does not require storing any secret values.
- The created token is scoped to a specific repository or workflow.
- Implementing OpenID Connect avoids the need to recycle service principal secrets.
This post includes plenty of links. You can find a working example online in the “OIDC-fab-deploy.yml” file in my GH-fabric-cicd-sample Git repository in GitHub.
Preparing to work with OpenID in GitHub
To prepare working with OpenID Connect in GitHub I first created a new app registration in Microsoft Entra. I then navigated to manage->Certificates & secrets->Federated credentials and selected “Add credential” as below.

One key point that I need to highlight is that the details that you enter here are case sensitive when working with GitHub.
Once configured, I verified that my application had a valid role in Microsoft Entra to ensure that a token was created. Afterwards, I created my GitHub Actions workflow.
GitHub Actions workflow to perform Fabric CI/CD securely
I created a new GitHub Actions workflow in the “OIDC-fab-deploy.yml” file. I then gave it a sensible name and configured the triggers. You can change the triggers to whichever branch you work with to suit your needs.
name: Deploy securely with OIDC and fab deploy
#Sets the trigger to manual
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
Afterwards, I added the relevant permissions for the workflow and the checkout action. Before calling the action itself.
jobs:
test:
permissions:
id-token: write # Require write permission to Fetch an OIDC token.
contents: read
runs-on: windows-latest
steps:
# Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
- uses: actions/checkout@v6
with:
token: ${{ secrets.GITHUB_TOKEN }}
I then specified a version of Python and installed the relevant Python libraries.
# Use specific version of Python
- name: Setup Python
uses: actions/setup-python@v5.5.0
with:
python-version: 3.12
# Install necessary libraries
- name: Install necessary libraries
run: |
python -m pip install --upgrade pip
pip install ms-fabric-cli
Next, I added the below PowerShell.
- name: Log in to Fabric CLI
env:
FAB_CLIENT_ID: ${{ secrets.AZURE_CLIENT_ID }}
FAB_TENANT_ID: ${{ secrets.AZURE_TENANT_ID }}
shell: pwsh
run: |
fab config set encryption_fallback_enabled true
$tokenUrl = "$env:ACTIONS_ID_TOKEN_REQUEST_URL&audience=api://AzureADTokenExchange"
$response = Invoke-RestMethod -Uri $tokenUrl -Headers @{ Authorization = "Bearer $env:ACTIONS_ID_TOKEN_REQUEST_TOKEN" }
$FED_TOKEN = $response.value
fab auth login -u $env:FAB_CLIENT_ID --tenant $env:FAB_TENANT_ID --federated-token $FED_TOKEN
fab ls
This script builds the OIDC token request URL and appends the Azure federated audience that matches the “api://AzureADTokenExchange" value I set whilst creating the federated credential.
Followed by Invoke-RestMethod Invoke-RestMethod to pass the GitHub-provided bearer token in order to retrieve a federated token from GitHub’s OIDC endpoint.
The system saves the returned token value and then calls the fab auth login command. Specifying the Fabric app’s client ID and tenant ID, plus the federated token. Which authenticates the Fabric CLI using the GitHub OIDC flow instead of a secret.
Final step in my GitHub Actions workflow utilized the fab deploy command to deploy to the specified workspace.
- name: Deploy workspace items with Fabric CLI
shell: pwsh
run: |
fab deploy --config "./workspace/config.yml" --target_env "${{vars.TargetEnvironment}}" -f
if ($LASTEXITCODE -ne 0) {
throw "Fabric CLI deploy failed for target environment: ${{vars.TargetEnvironment}}"
}
Checking the GitHub Actions workflow to ensure performs Fabric CI/CD securely
For certainty, I asked GitHub Copilot in Visual Studio Code if the solution was secure enough for production and it came back with the below recommendations:
- Yes, the OIDC pattern is more secure than using a stored client secret.
- But for Production you should also:
- enforce Azure federated credential restrictions
- ensure the service principal has least privilege
- avoid automatic deploys from PRs unless that is intentionally gated
- consider adding a manual approval or environment protection for production deploys
Testing the GitHub Actions workflow
After creating the workflow locally I created a new GitHub repository an added the AZURE_CLIENT_ID and AZURE_TENANT_ID secrets. Plus, the TargetEnvironment variable which I set to Test. I then synchronized my local Git repository and checked the workflow had completed as below:

Epilogue
With this method you can perform Fabric CI/CD securely in GitHub with OpenID Connect and fab deploy. There are variations that you can work with instead. For example, deploying with the fabric-cicd Python library directly.
Anyway, feel free to clone the “OIDC-fab-deploy.yml” file and experiment for yourselves.
1 thought on “Perform Fabric CI/CD securely in GitHub with OpenID Connect and fab deploy”