When deploying resources to Azure from GitHub Actions, using service principals and storing secrets is no longer the best approach for any DevOps Engineer out there. Federated Identity gives you a cleaner, safer way to authenticate. There are no secrets to manage, no credentials to rotate, and nothing sensitive stored in your repository.

With Federated Identity, you connect your GitHub repository directly to an Azure-managed identity using OpenID Connect (OIDC). When your workflow runs, GitHub hands over a temporary token. Azure checks that token and, if everything matches, allows the pipeline to access the resources it needs. It's automatic, secure, and fully managed.

This setup makes sense when you want to avoid long-lived credentials and reduce the risk of secrets being exposed to the internet. It’s also a great fit when your deployment process needs to scale, and you don’t want to spend time maintaining service principals or rotating secrets. If you’re working with multiple environments like dev, staging, and prod, you can give each workflow its own identity and limit access based on what’s actually needed. That keeps things secure and tidy.

Federated Identity becomes especially useful in DevOps teams working across multiple cloud providers or managing complex environments. It gives you consistent, secure access to Azure without the overhead of traditional credentials approach. You keep control, simplify your pipeline, and improve security all at once.

How Does the Deployment Workflow Look?

Once you’ve set up Federated Identity between GitHub Actions and Azure, the deployment workflow becomes straightforward and repeatable. No secrets, no guesswork - just a clean pipeline from code to cloud.

Here’s what that process looks like in practice.

It starts with a developer pushing code to the GitHub repository. This push triggers the GitHub Actions workflow, which is already wired up to handle authentication and deployment.

Next, instead of using a stored secret or service principal, GitHub Actions requests a token through OpenID Connect. This token is passed to Azure, where it’s validated against the managed identity you configured earlier. If the request is valid, Azure grants the workflow the exact permissions it needs - nothing more.

With authentication complete, the workflow moves on to deploy resources in Azure. This could mean provisioning infrastructure like virtual machines, app services, or storage accounts using Bicep, ARM templates, or Terraform. Whatever tool you’re using, the key point is that it now has secure, scoped access to do the job.

Finally, the pipeline monitors the deployment. It checks if the resources were created as expected, captures logs, and reports back. If something fails - like a missing permission or a misconfigured parameter - you’ll catch it here.

This end-to-end flow keeps the whole process automated, secure, and easy to debug when things go unexpected. 

How Do You Integrate Azure Federated Identity for Azure Deployments?

Now that we understand the value of Federated Identity, let’s walk through how to set it up in Azure. The goal is to create a trusted connection between GitHub Actions and Azure without using service principals or secrets. Everything is based on temporary tokens issued by GitHub and validated by Azure.

To enable secure deployments from GitHub Actions to Azure using Federated Identity, the process starts in Microsoft Entra ID. Rather than jumping straight into managed identities, you first need to register an app that Azure can use to validate GitHub-issued tokens through OIDC (OpenID Connect). This app acts as the identity link between your GitHub repository and Azure.

Start by going to Azure Portal → Microsoft Entra ID → App registrations. Click New registration and create a new application. 

Once registered, you’ll land on the app’s overview page where you’ll see the Application (client) ID, Object ID, and Directory (tenant) ID. These values uniquely identify your app in Azure and will be referenced later in the GitHub workflow configuration.

Next, move to the Federated credentials tab inside the app registration. This is where the trust relationship with GitHub Actions is defined. Click on Add credential, then select the use case GitHub Actions deploying Azure resources. 

You’ll be asked to provide your GitHub organization, repository, and the branch to restrict access. In this example, the organization is Cipher-08, the repository is azure-pi, and the branch is main.

Azure will generate the subject identifier in this format:

repo:Cipher-08/azure-pi:ref:refs/heads/main

This tells Azure to only trust tokens issued by GitHub Actions workflows that run in this repo and on this branch.

Once saved, the federated credential is now visible in the list. This confirms that Azure trusts GitHub to issue identity tokens for this repo.

Now switch to Access control (IAM) in Azure. Navigate to the subscription or resource group where you plan to deploy infrastructure and assign the appropriate role to the app you just registered. 

Typically, you’ll grant it the Contributor role scoped to a specific resource group. This gives it enough permissions to create and manage resources without over-provisioning.

At this point, Azure is configured to trust GitHub and your app has the required permissions to deploy resources. The next step is to update your GitHub repository to use this configuration in an actual workflow.

How Do You Run the Pipeline for Secure Deployments Using GitHub Actions?

With the federated identity and access controls configured in Azure, you can now build a GitHub Actions workflow that uses this setup to deploy infrastructure securely.

In your GitHub repo, define a workflow in .github/workflows/, triggered on a push to the main branch. Make sure to grant the workflow the right permissions: id-token: write is essential for generating the federated token, and contents: read lets the job pull the code.

Here’s what the YAML looks like:

The Azure login step uses the federated identity credentials you set up. When this runs, GitHub generates an identity token and Azure validates it - if everything checks out, the workflow is authenticated as the app you registered.

The Azure login step uses the federated identity credentials you set up. When this runs, GitHub generates an identity token and Azure validates it - if everything checks out, the workflow is authenticated as the app you registered.

Terraform uses the identity to deploy infrastructure. In this setup, a basic resource group is created using values from variables.tf. The provider is configured to use OIDC so that Terraform can authenticate using the federated identity token issued during the GitHub Actions workflow.

Here’s what the Terraform files look like for this deployment:

This file configures the Azure provider to use OIDC and deploys a single resource group using the variables defined in the variables.tf file.

These variables are injected into the GitHub Actions workflow through environment variables or defaults, and passed into terraform apply to create the resource group.

This minimal setup is enough to verify that the federated identity and the OIDC authentication flow work end to end. Once confirmed, you can extend it to deploy your infrastructure using modules, remote state, and more complex provisioning logic - all without managing any kind of secrets.

Best Practices for Integrating Federated Identity Credentials with GitHub Actions

Now that everything is wired up and running, let’s talk about keeping it secure and stable over time. Setting up Federated Identity is just the start - how you maintain and extend it makes all the difference in long-term reliability and security of your infra.

Use Managed Identities for All Services

Once your initial workflow is in production, the best thing you can do is make managed identities the default for any service that needs to connect to Azure. If a resource or service supports Managed Identity, use it. The fewer static credentials floating around your systems, the smaller your attack surface. This isn’t just about GitHub Actions - apply the same thinking across scripts, tools, and long-running apps.

Regular Auditing and Monitoring

Every time a GitHub Actions workflow uses Federated Identity to access Azure, that activity is logged. Azure records when a token was requested, which identity was used, and what actions were performed. These logs are available in Azure Activity Logs and Entra sign-in logs. You can use them to track how each identity is being used and spot anything unusual.

Make it a habit to review these identities regularly. Check if any identities haven’t been used in a while. Remove them if they’re no longer needed. Also, check the permissions - if an identity was meant to deploy to a dev environment but still has access to production, that’s a risk. Keeping these clean helps prevent accidental changes in the wrong environment and limits the impact if something goes wrong.

Error Handling and Alerts

When any step fails in your pipeline - especially authentication - you need to catch it immediately. GitHub Actions logs will clearly show if the OIDC token was rejected by Azure. This usually happens when the federated credential doesn’t match the repository, branch, or environment you’re deploying from. Make sure your workflow includes proper status checks so failures are visible in pull requests. Use GitHub’s built-in notifications or set up integrations with tools like Slack, Microsoft Teams, or PagerDuty to alert your team when a job fails. 

Firefly: Transforming Your CI/CD Workflow

Everything we’ve built so far gets you to a secure, credential-free pipeline. Your infrastructure is deployed using GitHub Actions and Federated Identity. But as your infra scales - more teams, more modules, more environments - visibility becomes the next bottleneck.

You’ve got Terraform plans running in CI, but what exactly is getting deployed? Are you confident nothing’s being misconfigured? What’s the cost impact? Are policies being followed before terraform apply runs?

These questions are hard to answer when you’re looking at raw logs or reading plan output in a terminal. And that's where the current setup begins to fall short.

Firefly adds visibility, governance, and safety into your Terraform pipelines - without requiring major changes to your existing setup. It integrates directly into your CI/CD workflows and processes your Terraform plans during the Plan phase. Instead of scrolling through JSON or CLI output, you get a clean, visual breakdown of everything your deployment is about to do.

‍

The image above shows a terraform plan visualised in Firefly’s workspaces dashboard. It highlights that five Azure resources will be created, and how they’re dependent to each other - from the network interface and subnet to the storage account and virtual network. You can clearly trace relationships and spot potential misconfigurations at an early stage.

What’s even more useful is Firefly’s tagging and policy summary on the left. You can instantly see tag coverage (in this case, 0%), cost estimation ($0/m), and whether any policies are being violated. No need to grep through logs - it’s all visually displayed out clearly.

But visibility is just the start. Firefly enforces Guardrails - its built-in policy engine - to catch violations early, right after the Terraform plan is generated. These Guardrails let you enforce best practices, block unsafe changes, and make sure important controls like HTTPS-only storage or encryption-at-rest are never skipped.

In the image above, the pipeline is blocked because the storage account doesn’t have HTTPS-only traffic enabled. That’s not just flagged - it’s enforced. The run doesn’t proceed to terraform apply. This is what shift-left security looks like.

And it’s not just a red flag - Firefly explains the issue and tells you how to fix it.

Firefly’s AI remediation outlines the problem, why it matters, and even generates the Terraform snippet you need to fix it. No back and forth between DevOps and Security. 

Firefly doesn’t stop at the plan phase. It continuously monitors your infrastructure post-deployment for drift, policy violations, and cost inefficiencies. If someone changes a setting through the Azure Portal, or if a resource deviates from the approved configuration, Firefly will detect it and flag it immediately.

This gives you end-to-end confidence - from writing the Terraform, to reviewing the plan, to enforcing policies before deploy, and finally monitoring what’s live in production. Your CI/CD pipeline becomes more than just a delivery mechanism. It becomes a control point.

‍