Azure role-based access control
Azure role-based access control (RBAC) decides what a principal may do at a scope: a role assignment joins a principal, a role and a scope. The Azure Enterprise Baseline keeps every standing assignment for people in one matrix, grants it to Entra groups only, and narrows it from the sandbox toward production.
What it does
A role definition lists allowed actions (control plane, through Azure Resource Manager) and dataActions (data plane, such as reading a blob or a secret), with notActions carved out. A role assignment grants one role to a user, group or service principal at a scope: a management group, a subscription, a resource group or a resource. Assignments inherit downward. Built-in roles such as Owner, Contributor and Reader cover the control plane; data planes have their own roles, such as Key Vault Secrets User or Storage Blob Data Reader. A custom role defines its own action list, and a condition (attribute-based access control, ABAC) can narrow an assignment further, for example to one blob path.
How BuiltForProd uses it
The access matrix. The entra-rbac unit holds every standing assignment in two maps of modules/entra-rbac/main.tf: standing, always applied, and admin, standing only while Privileged Identity Management (PIM) is off. Each entry is a group, a role and a scope. The read-only role set is Reader, Log Analytics Reader and Monitoring Reader.
| Group | Core | Sandbox, dev | Staging | Prod |
|---|---|---|---|---|
| Platform Leads | Owner and Security Admin at mg-acme (admin) | via mg-acme | via mg-acme | via mg-acme |
| Platform Engineers | Contributor at mg-acme-core | Contributor | Contributor | Read-only set |
| DevOps Leads | Read-only set at mg-acme-core | Owner at mg-acme-plat (admin) | same | same |
| DevOps Engineers | Read-only set at mg-acme-core | Contributor | Contributor | Read-only set |
| Lead App, ETL and AI developers | none | Contributor | Contributor | through All Engineers |
| App, ETL and AI developers | none | Contributor | none | through All Engineers |
| All Engineers | none | none | none | Read-only set |
| Security Auditors, Lead Security Auditors | Security Reader and acme-security-auditor at mg-acme; the leads also Reader and Log Analytics Reader | inherited | inherited | inherited |
Humans get access through these groups only: a custom policy in the security guardrails initiative denies any role assignment whose principal type is User, below mg-acme.
Kubernetes access. Owner and Contributor carry no Kubernetes data actions, so the matrix grants the Azure Kubernetes Service (AKS) data-plane roles separately, and a group's Kubernetes access never exceeds its Azure access to the same stage:
| Group | Sandbox, dev | Staging | Prod |
|---|---|---|---|
| Platform Leads, DevOps Leads | RBAC Cluster Admin | RBAC Cluster Admin | RBAC Cluster Admin |
| Platform Engineers | RBAC Cluster Admin | RBAC Cluster Admin | RBAC Reader, Cluster User Role |
| DevOps Engineers | RBAC Writer | RBAC Writer | RBAC Reader, Cluster User Role |
| Lead App, ETL and AI developers | RBAC Writer | RBAC Writer | through All Engineers |
| App, ETL and AI developers | RBAC Writer | none | through All Engineers |
| All Engineers | none | none | RBAC Reader, Cluster User Role |
The two lead groups hold Cluster Admin at mg-acme-plat, standing even while their Owner is eligible through PIM; every other grant is per stage subscription. The auditor groups and ACME_BreakGlass hold no Kubernetes role. The Azure Kubernetes Service Cluster User Role carries the one action az aks get-credentials needs, which neither Reader nor RBAC Reader includes, so every reader on prod can fetch credentials and then only read.
Custom roles. Three are defined at mg-acme:
| Role | Defined in | What it allows |
|---|---|---|
acme-security-auditor | entra-rbac | Read security, policy, Key Vault, storage, network, monitoring and cluster configuration; no data actions |
acme-blueprint-deployer | github-oidc | Every action, locks and policy assignments included, except role, deny-assignment and policy-exemption changes, elevate access, subscription cancel or enable and a few sharing actions |
acme-tfstate-prefix-contributor | state-backend | Read, write, add and delete blobs of the tfstate container, with no container actions |
The blueprint infrastructure identities hold acme-blueprint-deployer on the four stage subscriptions, plus Role Based Access Control Administrator with a condition that allows creating or deleting assignments of an allow-listed set of roles only. They hold acme-tfstate-prefix-contributor with an ABAC condition that limits every blob action to their own key prefix, apps/app-blueprint/ or apps/etl-blueprint/. The Baseline identity and Platform Leads hold Storage Blob Data Contributor on the whole container and Platform Engineers Storage Blob Data Reader. GitHub OIDC describes the pipeline identities.
Terms you will see
| Term | Meaning |
|---|---|
| Role assignment | A principal, a role and a scope; the unit of access in Azure. |
| Data action | A data-plane permission, such as reading a secret; Owner and Contributor have none. |
| Read-only set | Reader, Log Analytics Reader and Monitoring Reader, granted together. |
standing, admin | The two maps of the access matrix; admin moves to PIM when PIM is on. |
| ABAC condition | An expression that narrows an assignment, such as a blob path prefix or a role list. |
Where to read more
- Azure Enterprise Baseline overview for the identity model as a whole.
- Microsoft Entra ID for the groups the matrix grants to.
- Least privilege for the principle the matrix follows.