CH02-03: Azure RBAC and Access Boundaries

Goal

The previous sections explained governance and landing zones. This section focuses on one of the first governance questions every Azure environment must answer:

Who can do what, and where?

Azure role-based access control, usually called Azure RBAC, is Azure's system for granting permissions to manage Azure resources. It helps teams decide who can read, create, change, delete, deploy, or administer resources at Azure scopes such as management groups, subscriptions, resource groups, and resources.

This section is not a role catalog. The goal is to understand the access model well enough to make better architecture decisions.

The Short Version

Azure RBAC connects three things:

Role assignment
  |
  +-- Who?    User, group, service principal, or managed identity
  +-- What?   Role definition, such as Reader, Contributor, or Owner
  +-- Where?  Scope, such as management group, subscription, resource group, or resource

The durable mental model is:

In Azure RBAC, the role says what, and the scope says where.

For example, giving a group the Reader role at a production management group means the group can read resources across the production subscriptions under that management group. Giving the same group Reader on one resource group limits the access to that resource group.

Scope changes the blast radius of the permission.

Why Access Boundaries Matter

Access control is not only a security detail. It affects how teams build and operate systems.

Access decisions influence:

Who can deploy changes.
Who can troubleshoot production incidents.
Who can view sensitive configuration.
Who can delete resources.
Who can assign access to others.
Which automation identities can create or update infrastructure.
How easily auditors can understand who had permission.

A weak access model often starts innocently. A team is blocked, so someone grants broad Owner access at a subscription. A deployment pipeline fails, so the pipeline identity gets more permissions than it needs. A contractor needs temporary access, but the assignment is never removed.

Those shortcuts create long-term risk. Azure RBAC helps prevent that risk when roles and scopes are chosen intentionally.

Security Principals

The "who" in Azure RBAC is called a security principal.

Common security principals include:

Principal Type	Plain-Language Meaning	Example Use
User	A person with an identity in Microsoft Entra ID.	A support engineer receives temporary read access.
Group	A Microsoft Entra group containing users or sometimes other principals.	A product team group receives contributor access to its non-production resource group.
Service principal	An application or automation identity.	A CI/CD pipeline deploys infrastructure.
Managed identity	An Azure-managed identity attached to a resource or workload.	An app reads secrets from Azure Key Vault without storing credentials.

Microsoft Entra ID is Microsoft's cloud identity service. It provides the users, groups, applications, and workload identities that Azure RBAC can use.

In most human-access scenarios, assign roles to groups rather than individual users. Group-based access is easier to review, automate, remove, and explain. Direct user assignments are sometimes necessary, but they become hard to audit when used casually.

Role Definitions

The "what" in Azure RBAC is the role definition.

A role definition describes the allowed actions. Azure includes many built-in roles, and organizations can also create custom roles when built-in roles are too broad or too narrow.

For a starting mental model, know these common built-in roles:

Role	What It Means	Common Use
Reader	Can view resources but cannot change them.	Auditors, security readers, stakeholders, support visibility.
Contributor	Can create and manage resources but cannot grant access to others.	Application teams or deployment identities that need to manage resources.
Owner	Can manage resources and assign access to others.	Highly trusted administrators at carefully chosen scopes.
User Access Administrator	Can manage user access to Azure resources.	Access administrators who should manage permissions without owning all resource configuration.

Do not memorize every Azure role now. The key is to choose the least powerful role that supports the responsibility.

Owner is especially sensitive because it includes the ability to grant access. A person with Owner at a broad scope can change resources and give other people access. That may be appropriate for a small number of platform administrators, but it should not be the default for application delivery.

Scopes

The "where" in Azure RBAC is the scope.

Azure RBAC can be assigned at several scopes:

Management Group
  |
  +-- Subscription
      |
      +-- Resource Group
          |
          +-- Resource

Permissions assigned at a broader scope are inherited by lower scopes. If a group receives Reader at a management group, it can read resources in child subscriptions. If a deployment identity receives Contributor at a resource group, it can manage resources inside that resource group.

Use broad scopes for broad responsibilities. Use narrow scopes for narrow responsibilities.

Scope	Example RBAC Use
Management group	Central security readers can view all production subscriptions.
Subscription	Platform operators can manage shared connectivity resources.
Resource group	An application team can deploy and manage one workload component.
Resource	A specific automation identity can read secrets from one key vault.

Resource-level assignments are sometimes useful, but they should not become the normal pattern for everything. Too many one-off assignments are hard to audit and easy to forget.

Production and Non-Production Access

Production and non-production usually need different access patterns.

In non-production, teams often need more freedom. Developers may need to create, change, test, and delete resources quickly. The environment still needs guardrails, but the operational risk is lower.

In production, access is usually tighter. Fewer people should have direct write access. Changes may go through deployment pipelines. Break-glass or emergency access may exist, but it should be controlled, visible, and reviewed.

A simple pattern might look like this:

Environment	Example Access Pattern	Reason
Development	Product team has Contributor at a development resource group or subscription.	Supports fast iteration.
Test	Product team has Contributor with policy controls and cost limits.	Supports validation while keeping governance visible.
Production	Deployment identity has scoped Contributor; operators have limited write access; team has Reader.	Reduces manual change risk and improves auditability.
Production security view	Central security has Reader or security-specific roles at a production management group.	Enables oversight without making security the owner of every workload.

This is only a pattern, not a universal rule. Some teams need different production access for operational reasons. The important point is that access should be intentional and explainable.

RBAC for Automation

Modern Azure environments are often deployed by pipelines, infrastructure as code, scripts, or platform automation.

Those automation tools also need identities. A pipeline identity should have enough permission to deploy the resources it owns, but not broad permission to change unrelated environments.

For example, a deployment identity for the customer portal should not automatically have Contributor across every production subscription. It may only need Contributor on one resource group, or a custom role that allows specific actions.

Managed identities are important here. A managed identity is an Azure-managed identity that an Azure resource or workload can use to authenticate without storing passwords or secrets in code. For example, an application can use a managed identity to read secrets from Azure Key Vault, which is Azure's service for securely storing secrets, keys, and certificates. You do not need Key Vault details yet; the governance point is that workload identities should receive scoped access just like human users.

RBAC Is Not Application Authorization

Azure RBAC controls management access to Azure resources. It is not the same as authorization inside your application.

For example, Azure RBAC can decide whether a developer can modify an Azure App Service resource. Azure App Service is a managed Azure service for hosting web applications and APIs. RBAC does not decide whether an end user of the hosted application can view an invoice or approve a payment inside the application. That application-level authorization belongs to the application design.

This distinction matters. Do not assume that because Azure RBAC is configured, the application itself has the right user permissions. Cloud management access and application business access are related security topics, but they are not the same control.

RBAC and Azure Policy Work Together

Azure RBAC controls who can act. Azure Policy controls what resource state is allowed or required.

For example:

RBAC may allow a team to create storage accounts in a subscription.
Azure Policy may deny storage accounts in unapproved regions.
RBAC may allow a deployment identity to create a virtual machine.
Azure Policy may require specific tags or audit missing diagnostic settings.

This combination is powerful. RBAC grants responsibility. Policy keeps that responsibility inside organizational rules.

The next section focuses on Azure Policy in more detail.

Example: Payments Team Access

Imagine a payments team that owns a regulated workload.

The team needs speed in development, control in production, and central security visibility.

A simple RBAC model might be:

Group or Identity	Scope	Role	Why
Payments developers	Non-production resource groups	Contributor	Developers can build and test quickly.
Payments production operators	Production resource groups	Reader plus limited operational roles where needed	Operators can inspect production and perform approved actions.
Payments deployment pipeline	Production application resource group	Contributor	Production changes go through the pipeline.
Central security readers	Production management group	Reader or security-specific role	Security can inspect production posture across subscriptions.
Platform network operators	Connectivity subscription	Contributor or network-specific role	Platform team manages shared network resources.

This model is not perfect for every organization, but it demonstrates the design thinking. Access follows responsibility. Production is tighter than non-production. Shared platform resources have different owners from workload resources. Automation identities are scoped to what they deploy.

Common Mistakes

Assigning Owner when Contributor or Reader would be enough. Owner includes permission to grant access, so it should be used carefully.
Assigning access directly to individual users by default. Group-based assignments are usually easier to manage and review.
Using broad scopes for narrow responsibilities. A resource group assignment may be safer than a subscription assignment when a team owns only one workload component.
Forgetting inherited permissions. A role assigned high in the hierarchy can grant access across many child scopes.
Creating too many one-off resource-level assignments. They may solve immediate problems, but they become hard to audit.
Confusing Azure RBAC with application authorization. RBAC controls Azure resource management, not every permission inside an application.
Treating RBAC as a replacement for policy, networking, backup, or monitoring. Access control is one part of governance, not the whole design.

If Someone Asks You

If someone asks, "How does Azure RBAC work?" a clear answer is:

Azure RBAC grants permissions by connecting a security principal, a role, and a scope. The security principal is who receives access, such as a user, group, service principal, or managed identity. The role defines what actions are allowed, such as Reader, Contributor, or Owner. The scope defines where the permission applies, such as a management group, subscription, resource group, or resource. In Azure RBAC, the role says what, and the scope says where.

This answer shows the model instead of only naming roles.

What You Should Remember

Azure RBAC is the governance control for access to Azure resources.

The most important idea is this:

Access should match responsibility, and scope controls blast radius.

Use groups where possible, choose the least powerful role that fits the job, separate production and non-production access, and be careful with broad assignments. RBAC gives teams the ability to act; it should not quietly give them more responsibility than they actually own.

Questions to Check Your Understanding

What are the three parts of a role assignment?
Why does scope matter in Azure RBAC?
Why are group-based assignments usually better than direct user assignments?
How should production and non-production access usually differ?
How is Azure RBAC different from Azure Policy?