We have several Terraform repositories hosted on on-premises GitHub Enterprise Server that deploy Azure infrastructure. Until now, deployments have been manual: an operator runs az login, then executes Terraform plans and applies. We want to move to proper GitHub Actions CI/CD using service identities instead.
The deployments have very different permission requirements. One creates a storage account and virtual network, links that network to a Virtual WAN hub in another subscription, and creates private DNS resources in that subscription. Another deployment only creates a virtual machine. Some workflows may also create new subscriptions, which means their identity would need permissions above the individual subscription scope.
For production use with self-hosted GHES runners, should we use Entra application registrations with federated credentials, user-assigned managed identities, or another approach? We also need to understand how authentication works when GHES is hosted on-premises and is not publicly accessible.
2 Answers
The important limitation is where the pipeline runs. GitHub-hosted runners can commonly use Azure OIDC federation directly, and a user-assigned managed identity is a good target for that setup. With on-premises GHES, you need to verify that your GHES version and network design support the required OIDC issuer and token exchange. If Entra cannot reach or validate the GHES OIDC endpoints, the standard federation flow may require exposing specific GHES endpoints, which may not be acceptable.
If GHES OIDC federation is not feasible, use a tightly controlled alternative such as a service principal with a certificate stored through your approved secrets system, or run the deployment through an internal broker or Azure-hosted deployment service. Avoid long-lived client secrets where possible. Regardless of the authentication method, separate identities by environment and subscription, use least-privilege role assignments, and keep subscription-creation permissions isolated from ordinary Terraform deployments.
The preferred pattern is workload identity federation rather than storing a client secret. Create an Entra application registration or user-assigned managed identity, configure a federated credential for the workflow identity, and grant that identity only the Azure roles it needs. For larger environments, use separate deployment identities: typically one per subscription or workload, with a more privileged identity reserved for subscription creation or management-group-level operations. This keeps the VM deployment from receiving the broad permissions needed by the cross-subscription deployment.
The runners will be self-hosted on our on-premises GitHub Enterprise Server and will deploy into our Azure tenant.
That GHES networking and OIDC requirement is exactly what I was concerned about. We need to confirm whether exposing the issuer endpoints is acceptable before choosing federation.