Skip to content

Access, Groups and PIM

The spoke groups

Every spoke gets four Entra ID security groups, named from the workload and environment. Your team's existing group (the display name in ProductTeamGroupNames) is made a member, either directly or just-in-time through PIM.

Group Azure role Typical members
…_Readers Reader Everyone on the team who needs to look
…_Contributors Contributor Engineers who change resources
…_Owners Owner Few people; mostly the deployment identity
…_Support Support access; always eligible with approval Support staff of the platform team

The exact group names follow your platform's naming template (a typical pattern is SG_SPOKE_<workload>_<env>_<role>).

What the roles are for

Role Use it to
Reader Look at resources and logs. Low risk, so it is often granted permanently.
Contributor Create and change resources. In acc and prd this is normally for emergencies and short troubleshooting, because changes there go through pipelines.
Owner Manage access and everything else. Few people need it, and the deployment identity (the spoke service principal) usually does the work.

Roles are assigned to groups, not to individual users. Elevated roles for people are a last resort. Day-to-day changes go through the deployment identity and your pipelines.

Choose how each role is granted

Per role (Readers, Contributors, Owners) the platform team sets one of three modes when it creates the spoke:

Mode (PIMGroupConfig) You get the role Use it for
nopim Permanently, through group membership Development and test; low-risk roles
self-approve When you activate it in PIM; no approval Elevated roles where an audit trail is enough
approval When you activate it in PIM and an approver accepts Production owners and contributors

A common approach is nopim in dev and tst, and approval for Contributors and Owners in prd. Ask for a change in mode through How to change.

An example per environment

One customer platform used this setup. Yours can differ, because the mode is set per spoke.

Role dev tst acc prd
Readers nopim nopim nopim nopim
Contributors nopim self-approve approval approval
Owners nopim approval approval approval

Reader is low risk, so it is always direct. dev favours fast feedback. From tst on, elevated roles leave an audit trail, and from acc on they need a second person.

What happens behind the scenes

The spoke baseline uses PIM for Groups. Your team's group becomes a member of each spoke group. In nopim mode the membership is active and permanent. In self-approve and approval mode the membership is eligible: your people hold no role until they activate it, and it ends on its own. The role itself is always assigned to the spoke group on the subscription, so activating the group membership is what gives the role. More background: PIM for Groups.

Activate a role in PIM

  1. Open the Azure portal and go to Privileged Identity Management.
  2. Choose My roles, then Groups.
  3. Find the spoke group and choose Activate.
  4. Pick a duration (up to the maximum allowed), give a clear reason, and confirm.
  5. With approval, the request goes to the approvers. Follow it under My requests: Pending, Approved, Denied or Expired.

Role activations are always temporary and expire on their own. Before you request access, find the group by your workload short name in the PIM Groups list. Give a clear reason (for example the change or incident number), because every activation and approval is logged and may be audited.

Approvers

If you are an approver: you get an e-mail. Open PIM, choose Approve requests, then Groups, review the request carefully (Owner rights are sensitive) and select Approve or Deny with a comment. Keep the approver group small. Elevated rights should rarely be needed, because normal changes go through pipelines.

Who may approve depends on the platform. A common choice is the members of the workload's own team group, plus a few people of the platform team. On many platforms nobody can approve their own request. After you approve, the requester gets an e-mail that the request was approved, and another one when the access is active.

Who manages group members?

Group Managed by
Your team's own group (in ProductTeamGroupNames) You, or your identity team: add and remove your colleagues here. This is the way to give a person access.
The four spoke groups The platform. Don't edit their members or owners.

A product owner can manage group membership for the groups they own in the Microsoft self-service portal for groups (myaccount.microsoft.com/groups), if your organisation enables it.

Application groups and access reviews

Some organisations let workload teams request extra Entra ID groups for application-level authorisation, with optional PIM (and an automatically created approvers group) and periodic access reviews (Entra ID Governance) of the members. If your platform offers this, request it from the platform team with: group name, description, optional PIM group name and optional review frequency. The MCP spoke baseline itself only creates the four groups above.

For a group with PIM, a request usually also names the eligible group (the people who may activate) and the activation settings. These are the Entra PIM settings that platforms typically let you choose:

Setting Meaning
Maximum duration How long one activation may last, for example 8 hours
Justification Whether the user must enter a reason
Approval Whether an approver must accept the activation
Multifactor authentication Whether the user must perform MFA at activation
Ticket information Whether the user must give a ticket number
Notifications Who is notified of activations and approvals

A customer platform may keep these settings as code in a separate repository, with one policy file that several assignments reuse. Ask your platform team how application groups are requested in your organisation.

Adding members with Terraform

If you manage group membership as code, use azuread_group_member and pass both group_object_id and member_object_id explicitly. Lookups such as data "azuread_group" or data "azuread_user" need directory-wide read permissions, which the spoke service principal normally doesn't have. Find the object IDs first (portal or CLI) and put them in your code.