I'm designing a configuration-driven Azure Landing Zone deployment using infrastructure as code, such as Bicep, and Azure DevOps. The difficult part is securing identity and permissions for operations above the resource-group level, including management groups, subscription creation and placement, Azure Policy, policy assignments, RBAC, and other tenant or subscription configuration.
A service connection can be scoped to a subscription or resource group, but Landing Zone deployment often requires broader permissions. I'm concerned that if someone compromises an Azure DevOps project or pipeline with access to a highly privileged service connection, they could gain Owner or User Access Administrator-level control across the Azure estate.
How do you normally structure the identities, service connections, pipelines, and approvals for this? Do you separate platform and management-group deployment from subscription and workload deployment? Which permissions do you assign at the tenant, management group, subscription, and resource-group scopes? How do you handle operations that inherently require management-group or tenant-level access while ensuring that compromising a normal workload project does not compromise the entire tenant?
4 Answers
For high-impact actions, split permissions and operations further. Use different connections or identities for provisioning, deletion, and RBAC changes, restrict which pipelines can use them, and require manual approvals or policy checks for sensitive changes. Static analysis and policy validation in the pipeline can catch dangerous templates, but they should supplement—not replace—strong DevOps access controls. Ultimately, an unrestricted platform service connection is a tenant-level trust boundary, so access to it needs to be treated like administrative access to Azure.
Treat access to the Azure DevOps project and access to the privileged service connection as separate controls. Keep the platform or Landing Zone project restricted to a small platform team, and explicitly limit which pipelines are allowed to use each service connection. Service connection approvals, environment checks, protected branches, required reviewers, and pipeline permissions are useful defense-in-depth controls. Also consider just-in-time access through PIM for people who administer the platform.
One practical model is to use a dedicated platform identity with the minimum broad scope required for management-group and subscription operations, then create a separate identity for each Landing Zone or subscription. The Landing Zone identity can be Owner, or another carefully chosen role, only at that subscription scope. Federated workload identity or OIDC avoids storing long-lived secrets, but it does not remove the need to protect repository, pipeline, approval, and service-connection access—anyone who can modify trusted deployment code may effectively act as that identity.
Separate the platform foundation from workload delivery. A tightly controlled platform identity can manage management groups, policies, RBAC, and creation of Landing Zones, while workload identities are restricted to their individual subscriptions or resource groups. Use separate Azure DevOps projects and service connections for those layers, and limit the platform project to the platform or Cloud Center of Excellence team. Workload teams should not inherit access to the platform connection simply because they can deploy applications.
That makes sense. We currently rely mostly on environments and branch protection, but service connection approvals and stronger project restrictions would add another useful layer.