Identity is one of the first boundaries an Azure foundation establishes, and one of the hardest to repair after teams, subscriptions and automation have multiplied. Broad role assignments can make early delivery feel simple, but they also make it difficult to tell who owns a resource, who can change a control and which permissions an application actually needs.
A scalable identity design separates platform administration from workload operations. It gives each team enough access to do its work, keeps highly privileged actions deliberate, and lets applications authenticate without carrying credentials in code or configuration.
Establish ownership before assigning roles
Start with the operating model. Identify the platform team, workload owners, security responsibilities and the services that are shared across applications. Decide which controls remain centrally managed and which resource decisions workload teams can make within those guardrails. The subscription and management-group structure should make those responsibilities understandable rather than rely on one large group of administrators.
Use role assignments at the narrowest scope that still supports the job. Platform-wide policy and delegated administration may belong at a higher scope; application operators usually need access only to their own subscription or resource group. Keep resource management permissions separate from access to application data. Someone who can restart a service does not automatically need permission to read its database or secrets.
Separate routine work from privileged changes
Give people and automation only the permissions needed for their normal tasks. Prefer established Azure roles where they fit, and create custom roles only when the built-in permissions do not match a real responsibility. Assign roles to managed groups rather than individual users so that onboarding, transfers and offboarding update access through group membership.
High-impact roles such as Owner and User Access Administrator can change who has access, not just operate a workload. Keep these assignments limited, use a documented approval path, and make elevation temporary where the organization’s access model supports it. Review both active assignments and eligible privileged access; an approval process is useful only if the standing permissions are also controlled.
Separate control-plane permissions from data-plane permissions. A team that configures a storage account, key vault or database may not need to read its contents. Define those permissions independently, then verify that each workload identity and operator receives only the access needed for its task.
Give applications their own identity
Applications should not depend on a developer’s account, a shared administrator account or a long-lived secret embedded in a deployment setting. Use a managed identity when the Azure service supports it. The application can then request tokens through its hosting environment, while access is granted to that identity through a narrow role assignment.
Choose between system-assigned and user-assigned managed identities based on lifecycle and reuse. A system-assigned identity follows the lifetime of one resource. A user-assigned identity can be created and permissioned separately, and attached to more than one resource when that shared lifecycle is intentional. Avoid sharing one identity across unrelated applications or environments just to reduce setup work.
Keep environments isolated and access reviewable
Treat development, test and production as distinct security boundaries. Use separate workload identities, groups and role assignments for each environment. Promotion should move reviewed application artifacts and configuration through the delivery path, not carry a developer credential or privileged identity from one environment into another.
For recurring access, define an owner and a reason for each group and assignment. Review membership, scope and unused permissions when teams or workloads change. Log role changes and privileged operations, and make sure the people responsible for security and operations can investigate them.
A practical identity design sequence
- Governance scopeSet policy and privileged administration at the organization boundary.
- Platform scopeDelegate routine subscription and network operations to named platform roles.
- Workload scopeGive each application a managed identity with only its required access.
- Privileged changeUse time-bound approval, audit evidence and periodic access review.
- Map platform, workload and shared-service ownership to subscriptions and resource scopes.
- Define standard groups and role assignments for each workload environment.
- Separate resource administration from access to workload data and secrets.
- Use managed identities for application-to-service authentication where supported.
- Limit privileged role holders and establish an approved elevation and review process.
- Monitor role changes and revisit access when ownership or architecture changes.
The cloud foundation supplies the identity boundaries; platform engineering makes those boundaries repeatable through onboarding and deployment workflows. Design the access model around real ownership, then encode its standard assignments in the same reviewed path used to provision each workload landing zone.
Give automation a bounded identity lifecycle
Treat deployment identities as owned platform assets. Prefer workload identity federation or managed identities where the execution environment supports them, and avoid long-lived secrets embedded in repositories or pipeline variables. Scope each identity to the subscriptions or resources its job needs; a plan job that only reads state and inspects resources should not automatically inherit the permissions of an apply job. Assign an owner, review use and sign-in records, remove identities when the workload or pipeline is retired, and make credential rotation or federation changes part of the service’s operating procedure. These steps keep automation understandable as repositories and teams change.
Continue reading
References
- Landing zone identity and access management — Microsoft Cloud Adoption Framework.
- Azure role-based access control best practices — Microsoft Azure RBAC documentation.
- What are managed identities for Azure resources? — Microsoft Entra documentation.