Skip to content

Dedicated Group Manager

Teams that get a spoke also need access to a few resources outside the spoke. Examples are the central Bastion host, which gives access to their virtual machines (Connect to VMs), and a registry that holds the images of the managed templates. Adding every team group to those resources by hand does not scale. Instead, assign the role once to a dedicated group, and let a pipeline keep the team groups in that group.

This page describes that pipeline and its script, for the platform team.

Origin of this page

The script and the pipeline come from the spoke canvas of earlier versions, and the pipeline is an Azure DevOps pipeline. Names are those of the starter files. Check what your code version ships.

What it does

The script reads all spoke files, collects the team groups of every spoke, and keeps the dedicated group in line:

  • team groups that are not yet in the dedicated group are added;
  • team groups that are no longer in any spoke file (the spoke is gone) are removed;
  • an optional list of group names is always added, whether or not a spoke refers to them (for example a security team).

The pipeline triggers on a commit to main of the configuration repository, so the group changes on demand, as soon as a spoke is added or removed. Users do not run it.

flowchart LR
    c["Commit to main<br/>(spoke file added or removed)"] --> p["Pipeline"]
    p --> s["Script reads all spoke files"]
    s --> g["Dedicated Entra ID group<br/>(in an administrative unit)"]
    g -.->|"role assigned once<br/>on the resource"| r["Bastion, registry, ..."]

Not in scope

The script does not assign roles to the dedicated group. Assign the role (for example the registry pull role, or the right on the Bastion host) to the group yourself, as code.

Components

What Where Remark
DedicatedGroupManager.ps1 Scripts folder of the code repository Part of the platform. Do not change it in your copy.
DedicatedGroupManager.yaml pipelines folder of the configuration repository Starter file. Adapt it.

Set up the pipeline

  1. Create a pipeline from the existing YAML file in the configuration repository, with the name DedicatedGroupManager.
  2. Run it once by hand, to authorise the pool, the variable group and the service connection.
  3. Adapt the file:
Item Required What to do
Variable group Only if its name differs The pipeline uses the same variable group as the spoke deployment.
ref of the code repository Yes Use the tag of the code version you run. Update it on every upgrade.
ScriptArguments Yes See the parameters below.

An excerpt of the step, anonymised:

trigger:
  branches:
    include:
      - main

steps:
  - task: AzurePowerShell@5
    displayName: "Update group memberships"
    inputs:
      azureSubscription: $(ServiceConnectionName)
      ScriptType: "FilePath"
      ScriptPath: $(System.DefaultWorkingDirectory)/spokedeployment-tf/Scripts/DedicatedGroupManager.ps1
      ScriptArguments: -SpokeFilePath <spoke-folder> -TargetEntraGroup "<group-name>" -TargetEntraGroupAdminUnitId "<administrative-unit-id>" -AlwaysAddGroupsToTargetEntraGroup ""
      pwsh: true
Parameter Meaning
SpokeFilePath Where the script starts to search for spoke files. Normally keep the default.
TargetEntraGroup Name of the dedicated group, created in the administrative unit. Example: AllSpokeTeams.
TargetEntraGroupAdminUnitId ID of the Entra ID administrative unit in which to create the group.
AlwaysAddGroupsToTargetEntraGroup Comma-separated group names that are always members, for example "Security team,VM management". Empty for none.

Operate it

  • The pipeline uses the service connection of the spoke deployment. It must be allowed to manage groups in the administrative unit of the dedicated group.
  • After a spoke is removed (Delete a spoke), the next run on main removes its team groups from the dedicated group.
  • If a team cannot reach a central resource, check first whether its group is in the dedicated group, and whether the pipeline ran after the spoke file was merged.