What is RBAC Baseline in Azure Landing Zone?

 What is RBAC Baseline in Azure Landing Zone?

• In simple terms, an RBAC baseline is the default set of access roles and assignments that you apply across your Azure environment to ensure least privilege and role separation from day one.
• It’s not “every possible role” → it’s a starting point (baseline) that enforces good access hygiene for the Landing Zone.
• It defines who can do what, where, and at which scope (Management Group, Subscription, Resource Group).

 

RBAC Baseline Structure (CAF-aligned)

The baseline is typically built around role separation at 3 levels:

1. Platform Roles (manage the Landing Zone itself)

• Platform Owner → Full control over the platform layer (network hub, security, identity integration).
• Platform Contributor → Deploy/manage infra, but no rights to IAM.
• Platform Reader → Audit and monitor only.

2. Workload/Application Roles (for business apps in spokes)

• App Owner → Control over app resources in their own RG/spoke only.
• App Contributor → Can deploy/manage, but no IAM rights.
• App Reader → Read-only access for troubleshooting/monitoring.

3. Security & Governance Roles

• Security Reader → Read security configurations across all scopes.
• Security Operator → Can manage security configurations (e.g., Defender settings).
• Policy Contributor → Can assign/update Azure Policies.
• Billing Reader / Cost Management Contributor → For finance/cost teams.

 

 

Scope	Role	Who gets it
Tenant Root MG	Global Administrator (Entra ID)	Central IT only
Management Groups	Owner/Contributor (limited)	Platform team
Subscriptions (Platform)	Owner	Cloud Platform Team
Subscriptions (Workload)	Contributor	App Teams
Resource Groups	Owner/Contributor	App Owners/Developers (only in their RG)
All scopes	Reader	Security/Compliance team for visibility
Cost Management	Billing Reader / Cost Management Contributor	Finance/Procurement

 

 

Guiding Principles to Follow

1. Least Privilege → Nobody gets more rights than they need (no “Owner” for developers).
2. Role Separation → Platform vs App vs Security teams must be separated.
3. Scoped Access → Assign roles at smallest scope possible (RG > Subscription > MG).
4. Break-Glass Accounts → Keep 1–2 emergency Owner accounts at tenant root, protected with MFA/PIM.
5. Use PIM (Privileged Identity Management) → For all elevated roles (Owner, Contributor).
6. Standardize Assignments → Enforce via Azure Policy (e.g., deny assignments outside of MG/Subscription).
7. Use Groups not Users → Assign RBAC to Entra ID groups (Cloud-Platform-Admins, App-Team1-Contributors, etc.), not directly to users.

 

Example: RBAC Baseline in a Landing Zone

• Platform Subscription:
• Platform-Admins → Owner
• Platform-Ops → Contributor
• Security-Ops → Security Reader
• Workload Subscription (e.g., HR App):
• HR-App-Team → Contributor (only in HR RG)
• Security-Team → Reader (all RGs)
• Finance-Team → Cost Management Reader

 

Conclusion:
An RBAC Baseline ensures secure, governed, and segregated access in your Landing Zone from day one. It avoids the “everyone is Owner everywhere” chaos, and lays the foundation for policy-based governance and PIM enforcement.

Landing Zone with Multiple Subscriptions Vs Single Subscription

 

Landing Zone with Multiple Subscriptions

 Pros

1. Clear Separation of Concerns
• Shared Services, Prod, Non-Prod, Sandbox subscriptions → clean boundaries.
• Blast radius is reduced → one bad deployment won’t affect everything.
2. Governance at Scale
• Apply policies by subscription (strict for Prod, relaxed for Dev).
• Easier to enforce compliance consistently.
3. Scalability & Future Proofing
• Subscription limits are spread across environments.
• Ready for global growth and multi-region setups.
4. Cost Transparency
• Budgets & alerts per subscription.
• Easier chargeback/showback for business units/apps.
5. Security Posture
• Centralized Hub in Shared Services.
• Prod traffic never mixes with Dev; fewer lateral movement risks.
6. Operational Simplicity in Long Run
• Centralized LA workspace + DCRs in Shared Services.
• Single Bastion, Firewall, Private DNS hub → easier operations.
7. Audit & Compliance
• Industry best practice.
• Easier to pass regulatory audits with Prod isolat

 

Landing Zone with Multiple Subscriptions

Cons

1. Higher Initial Effort
• Some resources (RSVs, Managed Disks, Arc) cannot be “moved” → must redeploy or re-onboard.
• Requires re-addressing VNets if overlaps exist.

2. Cultural Change for Teams

·       App owners used to one subscription need training on new structure.

·       RBAC roles will need redefined at subscription level

  

Single Subscription Restructure

 Pros

1. Lower Initial Effort
• No need to move non-movable services (e.g., RSV, ASR, Managed Disks).
• Easier to keep existing resource IDs → avoids re-pointing dependencies.
2. Minimal Disruption
• Less chance of downtime during transition.
• App teams continue working with familiar subscription boundaries.
3. Faster Implementation
• Can re-organize into Resource Groups, consolidate NSGs, workspaces, and Bastions without subscription moves.

 

Single Subscription Restructure

Cons

1. Scalability Limits
• Risk of hitting subscription quotas (VNets, vCores, Public IPs).
• Harder to scale globally or across regions later.
2. Governance Pain
• Policies (e.g., “Prod must use ZRS storage”) cannot be applied selectively.
• More exceptions and overrides → governance drift.
3. Poor Blast Radius Control
• Security incident, policy misstep, or noisy workload can impact all environments.
4. Cost Management Limitations
• Cost alerts, budgets, and RBAC only work at subscription scope.
• Difficult to do chargeback/showback by environment or business unit.
5. Networking Complexity Remains
• With many VNets and multiple peerings, you still face mesh chaos.
• Central Hub exists, but within same subscription → less flexibility to isolate Prod/Non-Prod.
6. Compliance Risk
• Auditors may flag mixed Prod/Dev workloads.
• Some regulatory frameworks require Prod separation.
7. Future Migration Debt
• If you need subscriptions later, moving resources again is harder (e.g., RSV, Backup Vaults, Managed Disks, Arc servers must be re-onboarded).

 

Summary in comparison side by side:

Dimension	Single Subscription (Restructure Only)	Multi-Subscription Landing Zone (Recommended)
Initial Effort	Low – easier to keep resources in place; no moves for RSV, disks, Arc	Higher – some resources must be redeployed; requires migration planning
Disruption Risk	Minimal – most resources stay as-is	Moderate – dependencies may need reconfiguration (API Conn, RSV, App→Storage)
Scalability	Limited – at risk of hitting subscription quotas (VNets, vCores, IPs)	High – scale across multiple subscriptions; avoids hitting limits
Blast Radius / Isolation	None – Prod, Non-Prod, Dev mixed together	Strong – Prod, Non-Prod, Shared Services isolated by subscription
Governance & Policies	Hard – same policies apply to all, exceptions increase drift	Granular – strict policies for Prod, relaxed for Dev/Test
Cost Management	Weak – budgets/alerts only at subscription scope; hard to do chargeback	Strong – budgets per subscription; easy chargeback/showback
Networking	Complex	Simplified – Hub in Shared Services; clear Spokes per env/app
Security Posture	Higher risk	Strong
Monitoring & Operations	Fragmented	Unified – consolidate
Reliability & DR	Inconsistent	Consistent – standard backup/DR patterns per subscription
Compliance & Audit	Risky – auditors may flag mixed Prod/Dev workloads	Audit-friendly – Prod isolated; aligns with CAF/WAF best practices
Future Flexibility	Low – will eventually require painful split later	High – future-proof; easier to add new apps/regions/workloads
Business Impact	Short-term cost saving, but technical debt grows; harder to scale securely	Long-term resilience, compliance, and operational excellence; industry best practice