We have an Azure environment with multiple subscriptions, and users currently receive Owner and Contributor access at the tenant or root management-group level. Those permissions are inherited by every subscription and resource group. I'd like to redesign this around least privilege, clearer ownership, and a structure that can scale. What governance, management-group, role-assignment, and automation practices would you recommend? Would managing the setup with infrastructure as code, such as Bicep or Terraform, be the right approach?
4 Answers
Governance needs to come before the technical rollout. Agree with leadership on who owns and supports each service, document a RACI, and establish the minimum role and scope for every team. For privileged access, use just-in-time elevation through Privileged Identity Management or privileged access groups where licensing allows it. Moving directly from broad Owner access to a fully automated IaC model is a major operational change, so plan the transition, test access carefully, and communicate it to the teams involved.
Start by creating management groups around meaningful boundaries, such as production versus non-production, business units, or platform responsibilities. Move subscriptions into the appropriate groups, then assign only the permissions needed at the lowest practical scope. Bicep or Terraform can define the hierarchy, role assignments, and policy consistently, making the changes reviewable and repeatable.
First map what each team actually needs to do. Having Owner at the root is extremely risky because one compromised account could affect the entire estate. Most users should probably have Reader access broadly, with Contributor or narrowly scoped custom roles limited to the subscriptions, resource groups, or resources they operate. Use policies to prevent inappropriate Owner assignments, and pilot the new model on a couple of subscriptions before changing everything.
Avoid treating built-in Owner and Contributor roles as the default for every job. Define separate responsibilities for platform administration, subscription ownership, application operations, networking, and security. For example, application teams may manage their application resources while being blocked from changing authorization, networking, public IPs, or other platform-wide controls. Custom roles can provide that separation, with assignments scoped to the relevant subscription or resource group.
That makes sense. We’ll define the ownership and access model first, then automate the approved structure instead of trying to use IaC to solve the governance questions.