I'm designing a configuration-driven Azure Landing Zone deployment using infrastructure as code such as Bicep and Azure DevOps. I'm unsure how to handle identity and permissions for resources above the resource-group scope, including management groups, subscription creation and placement, Azure Policy, policy assignments, RBAC, and tenant-level configuration.
A service connection can be scoped to a subscription or resource group, but Landing Zone platform deployments may require management-group or tenant-level permissions. That creates a significant blast-radius concern: if someone compromises an Azure DevOps project or pipeline with permissions to create subscriptions, assign policies, or modify RBAC, they could potentially gain control of the entire Azure environment.
How do you structure the identities, service connections, pipelines, approvals, and permissions so that access to a normal Azure DevOps project does not expose the whole tenant? Do you use separate identities for platform management, Landing Zone provisioning, and workload deployments? Where do you scope each identity, and how do you protect operations that inherently require management-group or tenant-level permissions? Is it better to separate the platform hierarchy and shared services from individual subscription and workload deployments?
4 Answers
Treat access as several independent boundaries. Access to Azure DevOps should not automatically grant access to the Landing Zone project, and access to that project should not automatically allow use of its most privileged service connection. Restrict service connections to specific pipelines, require approvals and checks before they can be used, protect the repository and branches, and use just-in-time access where possible. Environments, approval gates, and protected branches are useful controls, but they need to be applied to the privileged platform pipelines rather than only to workload deployments.
Use defense in depth rather than relying on a single service-connection scope. Create separate connections for provisioning, updates, and destructive operations; restrict which pipelines can use each one; require manual approval for high-impact deployments; and add policy and IaC validation tools such as Checkov or equivalent. Keep subscription and workload deployments independent from the pipeline that manages the tenant hierarchy. Also treat Azure DevOps security as part of the cloud security boundary—if project membership, pipeline editing, or repository changes are broadly available, a highly privileged connection can still turn that access into tenant-wide control.
Separate platform management from workload delivery. A small platform team should own the management-group hierarchy, policies, subscription provisioning, and core RBAC through a dedicated project and tightly controlled pipelines. Workload teams should use separate projects and service connections scoped to their own subscriptions or resource groups. This is as much about organizational boundaries and ownership as it is about Azure role assignments.
A common model is to use one highly privileged platform identity for management-group operations, policy, RBAC, and subscription onboarding, then use separate identities for each landing-zone subscription. The landing-zone identity can be granted Owner or another narrowly designed role only at that subscription scope, limiting the impact of a compromise. Avoid reusing the platform identity for application deployment.
For authentication, workload identities or federated OIDC credentials are preferable to stored secrets. However, federation is not a permission boundary by itself: anyone who can modify the trusted repository, branch, or pipeline may be able to obtain that identity. Protect those trust conditions with repository permissions, branch policies, pipeline approvals, and narrowly scoped federated subjects. Review whether the platform identity truly needs permanent Owner access, and use PIM or equivalent just-in-time elevation for exceptional operations.
That makes sense. Just-in-time access, connection approvals, and deployment gates seem especially useful, although there is always pressure to optimize for delivery speed.