Unlocking Secure CI/CD with OpenID Connect

CI/CD workflows have become an essential part of modern software development, which dramatically improves the speed and reliability of software delivery. Looking back, it's hard to imagine how we managed to deploy applications by following a release checklist in a spreadsheet and manually clicking buttons in the Azure portal. Recently, I've been exploring different ways to authenticate GitHub Actions to Azure other than using Service Principal secrets. Even though it works as expected, managing the secrets increases the overhead of our workflow, especially when the security team requests the details of the secret’s usage. In this article, we'll explore how OpenID Connect (OIDC) can streamline this process, eliminating the need to store sensitive Azure secrets in GitHub and simultaneously enhancing visibility into service principal usage.

Setting Up Microsoft Entra ID for GitHub Actions

To enable GitHub Actions workflows to access Azure resources, the initial step involves registering an application in our Azure tenant and establishing a trust relationship. This process subsequently creates both an application object and a corresponding service principal object in our tenant. Initially, I was confused about the difference between an application object and a service principal. However, I finally got some clarity after a bit of investigation:

An application object serves as the global blueprint of an application, residing in the tenant where it was initially registered.
A Service principal, on the other hand, is the local representation instantiated from that application object in any tenant where the application is utilized.

In our particular scenario, once the application is registered in our tenant, the application object inherently resides there. For the application to become active and usable, a corresponding service principal is created within our tenant, based on this application object. The key distinction arises, however, when other tenants utilize our application. In such cases, additional service principals are created in those respective tenants, all stemming from our single application object. This design ensures that administrators can assign granular and appropriate permissions to each service principal directly within their tenant.

Creating Federated Credentials for OpenID Connect (OIDC)

After registering the application, the next step is to create federated credentials for the service principal. While there are other authentication options, such as client secrets or certificates, they come with several security and management challenges:

Secrets or certificates must be stored in GitHub
Manual rotation is required to keep them secure
Long-lived credentials increase security risk
Less granular access control

Given these concerns, OpenID Connect (OIDC) offers a more secure and maintainable solution. It eliminates the need to store secrets, supports short-lived tokens, and provides better traceability, making it a strong choice for authenticating GitHub Actions to Azure.

In addition, when setting up federated credentials, we can define a subject identifier that maps to specific GitHub workflows. This identifier can include the organization, repository, and entity type, like branches, environments, pull requests, or tags. This level of granularity allows us to restrict access to the service principal, ensuring only designated workflows with specific subject identifiers can interact with Azure resources.

Defining Permissions for the Service Principal

After creating the service principal, the next step is to assign it an appropriate role. In many cases, the Contributor role is a basic choice, as it grants permissions to create and manage Azure resources without the ability to modify roles and permissions. However, to enhance security, consider the following best practices:

Scope Minimization: Assign the Contributor role at the resource group level rather than at the subscription or management group level. This limits the service principal’s access to only the resources it needs to manage.
Policy Enforcement: Use Azure Policy to enforce governance and prevent excessive resource usage. For example, you can restrict the types of resources that can be deployed within a subscription.
Least Privilege with Custom Roles: When possible, define custom roles that grant only the specific permissions required for the task. While this approach requires more effort to design and maintain, it significantly reduces the attack surface.

Securing Azure Identifiers in GitHub Actions

While OpenID Connect (OIDC) removes the need to store sensitive Azure secrets directly in GitHub, the Azure Login action still requires a few key details for proper authentication. These include:

Azure Tenant ID – Identifies your Microsoft Entra ID tenant.
Azure Client ID – Refers to the service principal registered in Azure.
Azure Subscription ID – Specifies the subscription where resources will be deployed.

Even though these values aren't as sensitive as traditional secrets or certificates, it’s still a best practice to manage them securely. By storing them in GitHub Secrets, we can safely pass them to the workflow without exposing them in plain text.

To further enhance security, GitHub Environments enable us to restrict access to these secrets based on the deployment environment. For example, production deployment credentials can be safeguarded within a dedicated environment, accessible only by workflows that have secured explicit business approval.

Monitoring Service Principal Activity in Azure

To effectively monitor our service principal's activity, we can leverage Azure's built-in Sign-in Logs and Activity Logs. These invaluable tools provide visibility into both the federated identity's authentication attempts and the specific actions it has performed. For those who want to be more proactive, we can set up Azure Monitor to create alerts from these logs, ensuring we're promptly notified of any suspicious activity or unexpected access patterns.

Conclusion: Looking Ahead to Agentic Security

This has been an interesting study for me, as it has improved my understanding of Microsoft Entra ID and OpenID Connect. It's a valuable exercise in grasping identity and access management, especially concerning identities used by external programs. This knowledge becomes even more critical as we see agentic applications increasingly performing tasks on behalf of users. Ensuring proper access control for service accounts will undoubtedly be a vital security consideration going forward. As my next step, I will explore agent-specific access control management when I start learning agentic applications.

Thank you for reading.

Authenticate GitHub Actions to Azure using OpenID Connect