Overview
This reference implementation demonstrates enterprise-scale Azure access governance using group-based RBAC, Privileged Identity Management (PIM), and policy-enforced guardrails.
The architecture eliminates standing privileges for high-impact roles while preserving operational efficiency through just-in-time elevation and structured approval workflows.
All infrastructure is defined as code using Terraform and deployed through a controlled CI/CD pipeline with approval gates for RBAC modifications.
Context
Mid-sized enterprises often struggle with access governance as their Azure footprint grows. Direct user-to-role assignments proliferate. Standing Owner permissions become normalized. Policy enforcement is manual and inconsistent. The blast radius of a compromised account expands.
This project simulates a governance modernization initiative: migrating from ad-hoc access patterns to a structured model where privileged access is time-limited, approval-gated, and enforced through technical controls rather than process documentation.
Architecture
The implementation uses a layered governance architecture across management groups, custom roles, group-based RBAC assignments, and policy enforcement.
Management group hierarchy separates platform infrastructure (Identity, Connectivity) from application landing zones (Prod, NonProd). This separation enables distinct governance policies: platform teams operate under strict PIM-eligible assignments, while application teams receive resource-group-scoped active assignments appropriate to their blast radius.
RBAC assignments follow a group-only model. No direct user-to-role mappings exist. All access flows through Entra ID security groups, which are then assigned roles or marked as PIM-eligible. This simplifies access reviews and creates a single control plane for membership management.
Custom roles implement least privilege for CI/CD pipelines. The CR-AppDeployer roles grant deployment permissions (ARM templates, resource creation, Key Vault secret access) while explicitly denying dangerous actions such as role assignment or resource group deletion. This prevents service principals from privilege escalation or accidental infrastructure destruction.
Azure Policy provides preventive and detective controls. A deny policy blocks Owner assignments at subscription scope, forcing the use of PIM at the management group level. Audit policies track permanent privileged assignments, while tag policies enforce governance metadata on resource groups.
PIM configuration varies by role and persona. Platform Owner roles require approval and limit activation to two hours. Contributor roles allow shorter activation windows with reduced approval friction. External consultants receive shorter eligibility durations compared to internal employees. Activation policies enforce MFA and require written justification.
Repository Structure
The repository is organized around governance layers rather than technical services.
management-groups/– management group hierarchy and subscription placementcustom-roles/– least-privilege custom role definitionsrbac/– group-based role assignments and scope definitionspim/– PIM eligible role assignments and activation policiespolicies/– Azure Policy definitions and assignmentspipeline/– CI/CD pipeline implementing RBAC approval workflowsdocs/– supporting documentation and architecture notes
This separation reflects operational change patterns: management groups change rarely, custom roles occasionally, while RBAC assignments evolve more frequently as teams and projects change.
CI/CD Design
The pipeline implements a controlled approval workflow specifically designed for sensitive RBAC changes.
The validation stage performs Terraform formatting checks, security scanning, and module validation. This ensures configuration quality before any infrastructure planning occurs.
The plan stage generates Terraform plans for the different governance modules. RBAC-related changes are surfaced clearly in the plan output to make privilege modifications visible to reviewers.
A manual approval gate requires validation from both security and platform stakeholders. The review focuses on potential privilege escalations, scope changes, and confirmation that requested changes align with approved work items.
The apply stage executes modules sequentially in dependency order: management groups first, followed by custom roles, RBAC assignments, and finally policies. The pipeline applies the previously generated plan artifacts to guarantee that the reviewed changes match the deployed configuration.
Authentication for the pipeline uses workload identity federation rather than static service principal secrets. Terraform state is stored in Azure Storage with versioning enabled.
Infrastructure as Code Structure
Terraform modules are separated by blast radius and change frequency.
Management groups form the relatively static foundation of the platform structure. Custom roles change occasionally as governance requirements evolve. RBAC assignments change more frequently as team membership or project scopes evolve. Policies evolve with governance requirements.
Each module maintains its own Terraform state file. This allows independent planning and deployment while reducing lock contention during pipeline execution.
Remote state is stored in Azure Storage with blob lease locking enabled. Backend configuration is injected at pipeline runtime rather than hardcoded in source control.
Variable design separates static configuration (management group names, role definitions) from dynamic inputs such as subscription identifiers. Dynamic values are injected through pipeline variables.
PIM-eligible assignments are managed through Terraform resources to ensure consistent role eligibility definitions across environments.
Security Model
The architecture implements defense in depth across multiple layers.
High-impact roles do not have standing privileges. Owner and Contributor roles at platform scope are configured as PIM-eligible assignments. Users must activate the role with justification and approval.
Group-based access prevents role assignment sprawl. Azure Policy audits direct user-to-role assignments to enforce the group-only access model.
Custom roles restrict automation identities. CI/CD service principals cannot assign roles or modify authorization policies. They cannot delete resource groups or alter network topology. This limits the impact of compromised automation credentials.
Preventive policies block dangerous patterns. Owner assignments at subscription scope are denied, forcing elevation through PIM-enabled roles at higher governance levels.
A break-glass account provides emergency access. The credentials are stored outside the Azure environment and excluded from conditional access policies. Any usage of this account must be treated as a security incident.
Terraform state combined with pipeline approvals creates a verifiable audit trail. Every RBAC modification is associated with a Git commit and a pipeline approval record.
Engineering Considerations
Several design decisions reflect practical operational constraints.
Application teams receive resource-group-scoped Contributor roles rather than PIM-based elevation. This avoids operational friction for routine deployments while maintaining isolation between workloads.
Security teams receive specialized custom roles with targeted read permissions. This allows governance and compliance verification without granting broader privileges.
PIM eligibility durations balance security requirements with operational overhead. Internal employees receive longer eligibility windows, while external consultants receive shorter durations aligned with typical engagement periods.
Pipeline approval gates ensure RBAC modifications are reviewed in a structured workflow rather than applied directly through Terraform.
Key Learnings
- Group-based RBAC simplifies access reviews and user lifecycle management
- PIM workflows require clearly defined approvers and operational SLAs
- Custom roles for CI/CD identities reduce the risk of privilege escalation
- Policy deny controls enforce security boundaries more reliably than audit-only approaches
- Terraform combined with pipeline approvals creates an auditable access governance process
- Resource-group-scoped permissions often eliminate the need for PIM in application teams
- Break-glass credentials must be stored outside the protected environment
Scope
This project is a focused reference implementation demonstrating governance patterns, PIM integration, and infrastructure-as-code driven access management.
It is not a full production platform. Monitoring dashboards, automated access reviews, and ITSM integration are intentionally outside scope.
The emphasis is on architectural patterns: zero standing privileges, group-based RBAC, least-privilege automation identities, policy guardrails, and controlled RBAC modifications through CI/CD workflows.