End-to-end governance from DevOps to Azure

This article describes how to carefully manage and implement sound governance practices for your team, such as role-based access control permissions.

It's not sufficient to plan and implement an Azure role-based access control (RBAC) model for Azure Resource Manager templates (ARM templates), which restricts access via Azure portal and Azure CLI.

If this model isn't mirrored for DevOps automation, your organization might leave a security back-door open. Consider an example where a developer doesn't have access via ARM templates, but still has sufficient permissions to change application code or infrastructure as code and trigger an automation workflow. The developer, indirectly via DevOps, can access and make destructive changes to your ARM templates.

Single identity management plane with Microsoft Entra groups

The first step is to integrate Microsoft Entra ID to use single sign-on per identity management best practice.

If you aren't using an Azure first party CI product like Azure DevOps, check if your vendor offers Microsoft Entra integration.

The second step is to use Microsoft Entra groups, the same groups you're already using for your ARM templates RBAC model. It's a best practice to assign roles to Microsoft Entra groups, not to individuals. To create an end-to-end governance model, you will need to do this step for ARM templates and DevOps.

Azure DevOps has tight integration with Microsoft Entra ID including Microsoft Entra groups membership, making it easy to apply role assignments to the same Microsoft Entra group.

The following diagram illustrates how Microsoft Entra ID is used as the single identity management plane. In ARM templates and in our DevOps tooling (Azure DevOps in this example), we only need to manage role assignments, not memberships, which should be managed in Microsoft Entra ID. Note the resource names follow recommended naming conventions and abbreviations for Azure resources.

Example scenario: Remove contractor access with a single step, Microsoft Entra membership

To make end-to-end governance concrete, let's examine the benefits with an example scenario.

If you use Microsoft Entra ID as your single identity management plane, you can remove a developer's access to your Azure resources in one action, by adjusting their Microsoft Entra group memberships. For example, if a contractor's access should be revoked upon project completion, when you remove the contractor's membership from the relevant Microsoft Entra groups, access to ARM templates and Azure DevOps is removed.

Mirror RBAC model with role assignments

When planned well, the RBAC model in your CI tooling will closely mirror your Azure RBAC model. Although the Microsoft Entra group name examples in the diagram above imply security rules, membership alone doesn't enforce security. Remember that RBAC is a combination of principals, definitions, and scopes, which does not go into effect until the role assignment is created.

• The diagram illustrates role assignment for a single Microsoft Entra group, contoso-admins-group.
• This Microsoft Entra group is assigned the Owner role for Azure ARM templates at multiple subscription scopes:
  • contoso-dev-sub subscription
  • contoso-prod-sub subscription
• The contoso-admins-group is added to the Project Administrators group for Azure DevOps at a single project scope.

The Microsoft Entra group has similarly privileged roles for both ARM templates and DevOps. Following this logic, if we have a developer group assigned the Contributor role for ARM templates, we would not expect them to belong in the Project Administrators group for DevOps.

Now that you understand the need to secure ARM templates and DevOps workflows, you should:

• Review your RBAC model and think about how the roles and responsibilities you have defined for ARM templates match to your CI/CD workflow.
• Review your CI platform's identity management solutions and integrate Microsoft Entra ID. Ideally, you want to include the Microsoft Entra group membership.
• Review the roles and access levels offered by your CI tooling and compare them with your Azure RBAC model. The roles and access levels will not map one to one. Check your configuration. If a developer doesn't have access for ARM templates, they shouldn't have access for DevOps. In the simplest example, a developer who doesn't have write permissions to production resources shouldn't have direct access to trigger production pipeline runs.

To learn more about governance design and permissions, see:

• Recommended method for granting and restricting permissions
• Default permissions and access for Azure DevOps
• Managing people's access to your organization with roles

Next steps

Now that you understand the need to secure ARM templates and DevOps workflows, learn how to manage secrets in a secure way.