Identity and Access Model¶
This page describes the thinking behind access control on the platform. How you request and activate access as a consumer is in Access, groups and PIM. The exact groups of a spoke are in Spoke JSON reference.
Principles¶
- Make day-to-day work autonomous: a team should not need a ticket for ordinary tasks.
- High-privilege roles at tenant or platform level are always protected by PIM and authorised by people of the customer organisation, not by the managed service provider.
- Keep the model simple, to avoid complexity in implementation.
- Platform roles are assigned on management groups and inherited by the subscriptions below. Workload roles are assigned on the subscription and inherited by its resources.
- Roles and PIM assignments go to groups, never to individual user accounts that sign in interactively.
Layers and types of roles¶
Roles live on three layers.
| Layer | What it describes | Responsible |
|---|---|---|
| Business | The roles attached to a person: job title, function, department, location | The organisation (for example HR provisions and administers business users) |
| Workload | The roles on the level of a workload, which is a business solution that may contain several closely related applications | The platform provides a standard set of technical roles for each workload. Extra roles are possible but the workload team deploys and configures them. |
| Application | Roles inside one application, mostly native to it | The workload team |
Roles are also either technical or functional, because they need different expertise:
| Type | Focus | Examples |
|---|---|---|
| Technical | The inside of the workload or application: development, deployment, maintenance. High privileges on infrastructure. | Deploy resources, change configuration |
| Functional | The outside: business administration in the application, such as managing business users or workflows. Not infrastructure privileges. Delegated more often to people in other teams. | Manage application users |
Workload roles¶
A typical workload has four technical roles. Each is backed by an Entra ID security group that owns the permissions in the Azure portal, Azure DevOps and other services.
| Role | Meaning |
|---|---|
| Owner | Owns the workload and is finally accountable for everything in it |
| Approver | Approves changes and elevated access to production, for example PIM requests |
| Engineer | Responsible for the workload implementation and oversees it |
| Reader | Read access, for guests and supporting engineers or architects |
The MCP spoke baseline creates four groups per spoke: Owners, Contributors, Readers and Support, and sets whether
each role is permanent or must be activated in PIM with or without approval (see
Access, groups and PIM). Who approves is set in the PIM settings of the spoke groups.
A platform can add extra groups for application-level roles.
Note
If you design your own role set on top of the spoke groups, keep the owner of each group clear: the owner of the workload group owns the approver, engineer and reader groups.
Spoke groups and the spoke service principal¶
The four groups of a spoke have a fixed meaning on the subscription:
| Group | Role on the subscription | Notes |
|---|---|---|
Owners |
Owner | Includes access management. The spoke service principal is a permanent member |
Contributors |
Contributor | Everything except setting privileges |
Readers |
Reader | View only |
Support |
None | Has no privileges itself. It exists so that support staff of the platform team can reach the Owners group through PIM |
For Key Vault and storage, every group gets standing read access to the data plane, and Contributors and Owners can additionally activate elevated roles through PIM. The spoke service principal is Owner on the subscription, Key Vault Administrator on the Key Vault and Storage Blob Data Owner on the storage account, and gets no secret when federated credentials are used. Details, and how to override the role map: Spoke canvas.
The deployment that creates all of this is limited by an administrative unit: it can only manage groups in that unit. This is how the deployment identity keeps small privileges. See What the deployment identity needs.
Getting access to a workload¶
| Path | When | Why |
|---|---|---|
| The requester asks the workload owner, who adds the person to the team group | Normal | Access is limited to one workload and authorised by its owner |
| A platform engineer activates a Reader, Contributor or Owner role on a management group | Emergencies only | Gives access to all resources below that management group. Less preferred. Always through PIM and with a reason. |
Platform roles¶
Platform roles use the same principles with a wider scope.
| Principle | Detail |
|---|---|
| Assigned on management groups | The platform's core roles are set on management groups and inherited |
| Always through PIM | Contributor and Owner on platform scope are never permanent |
| An external platform team works as guest | The managed service provider's engineers are usually guests in the customer tenant. Some built-in policies flag guest accounts with write or owner permissions; see Governance. |
Microsoft Defender for Cloud¶
Authorisation in Defender for Cloud follows the Azure roles on the subscription:
| Action | Security Reader | Security Admin | Contributor | Owner |
|---|---|---|---|---|
| View alerts and recommendations | Yes | Yes | Yes | Yes |
| Edit security policy and assign initiatives | No | Yes | No | Yes |
| Enable or disable Defender plans | No | Yes | Yes | Yes |
| Apply a recommendation (Fix) | No | No | Yes | Yes |
This matches the Microsoft documentation. Check it before you rely on it.
Break-glass accounts¶
You can lock yourself out of the tenant if sign-in or privileged role activation fails. Reduce that risk with emergency access accounts:
- Create at least two. They are not assigned to a person.
- Use them only for emergencies where normal administrative accounts cannot be used.
- Store the credentials safely (for example in a vault and a physical safe). Decide who has access.
- Treat every sign-in with these accounts as high risk: alert on it and monitor it.
- Follow the current Microsoft guidance for emergency access accounts, including how to handle conditional access.
All roles and accounts with privileges at tenant level are high risk by default and should be monitored when used.
Service principals¶
Spoke deployments use a service principal per spoke. See What you get and Service principal and credentials. Prefer federated credentials to secrets, and rotate secrets before they expire (Operating responsibilities).