Establish hardened deployment trust relationships for CI/CD
Implementation Effort: High – Defining explicit pipeline-to-environment trust bindings and enforcing them with environment protections, reviewers, branch rules, and federated identity claims is sustained work across every pipeline. User Impact: Low – Configuring deployment trust boundaries and workload identity is an administrator and platform-team task; end users are not affected. Lifecycle Stage: Deploy
Overview
Define explicit trust relationships between each CI/CD pipeline and the environments it can deploy to, and enforce those relationships with environment protections, reviewers, branch restrictions, and workload identity claims.
No pipeline should be trusted to deploy to any environment simply because it ran successfully. Establishing hardened deployment trust relationships means defining explicit, verifiable bindings between specific pipelines and the environments they are permitted to reach. In GitHub Actions, environments with protection rules, required reviewers, and branch restrictions enforce these boundaries so only approved workflows can deploy to sensitive targets like production. In Azure DevOps, use environments, approvals and checks, branch control, exclusive lock, and service connection authorization to enforce the same deployment boundary.
When GitHub Actions uses OpenID Connect federation, Microsoft Entra validates the incoming token's issuer, audience, and subject claims against the configured federated credential before it issues an access token to the managed identity or app registration. Pair that trust with GitHub environment protections and branch restrictions so only approved repositories, refs, and workflows can request tokens for production deployments.
When Azure DevOps uses workload identity federation service connections, Microsoft Entra validates the service connection's federated issuer and subject during the token exchange. Pair that identity path with Azure DevOps environments, approvals and checks, branch control, pipeline permissions, and service connection authorization so only approved pipelines can reach sensitive targets; do not assume GitHub-style repository, branch, or environment claim parity in Azure DevOps.
After Microsoft Entra validates the federated credential and issues an Azure access token for the managed identity or service principal, Azure RBAC controls what that identity can access. Azure RBAC operates on the authenticated principal and has no visibility into the original OIDC token claims from GitHub or Azure DevOps.
Trust-boundary enforcement and resource permissions are therefore two distinct layers: the Entra token exchange validates repository, branch, and environment claims against the federated credential policy, while Azure RBAC enforces resource-level permissions for the resulting principal. Scope both deliberately.
A hardened pipeline path only reduces risk if it is the only path. Many organizations invest in a well-governed pipeline yet leave developers and operators with standing Owner or Contributor rights that let them deploy to production directly from a workstation, bypassing every environment protection, approval, and check described above.
Close that gap with defense in depth. Remove standing human write/deploy access to production resource groups and subscriptions, granting it just-in-time through PIM only for the rare break-glass case, and reserve resource-modifying RBAC on production scopes for the pipeline's workload identity. Back this with Azure Policy deny effects and deployment stacks with deny settings so changes that do not originate from the approved deployment identity are rejected at the resource manager.
The objective is that the CI/CD pipeline identity is the single supported route to production, so a compromised or careless human account cannot route around the controls. This complements the policy-as-code enforcement for critical Azure resources.
Without explicit trust boundaries, a single compromised workflow or a malicious pull request can escalate from a development context to a production deployment. Threat actors who gain control of a CI/CD pipeline — whether through a poisoned dependency, a stolen secret, or a compromised developer account — will attempt to pivot to higher-value targets. If the pipeline has broad, unconstrained access to production infrastructure, the blast radius is the entire environment.
Environment protection rules such as wait timers, separation-of-duties requirements that prevent self-approval, and deployment checks create layered checkpoints that slow down and surface unauthorized deployment attempts. Even if a threat actor compromises one stage of the pipeline, additional verification barriers remain before production access is granted. By validating repository, branch, and environment claims at the token exchange and scoping resource access to the pipeline's identity through just-in-time, least-privilege RBAC, this task supports Verify explicitly, Use least privilege access, and Assume breach.