Skip to content

Spoke Configuration Drift Detection

After a spoke is deployed, nothing stops its owners from changing the baseline resources. That is by design: it keeps the roles simple and the spoke flexible. Workload teams are not meant to change the baseline resources of the spoke canvas (What you get, Limits). The spoke drift detection pipeline shows what changed anyway.

It works like the weekly drift check of the hub (Maintenance calendar), for every spoke file: the pipeline plans each spoke and reports whether the plan wants to change resources. A planned change means that Azure no longer matches the code.

What it detects

Detection is limited. It finds what a Terraform plan finds: a difference between the state and the code, in the baseline resources of the spoke canvas. It does not check what the workload team deploys in the spoke on top of the baseline.

Origin of this page

The pipeline comes from the spoke canvas of earlier versions and is an Azure DevOps pipeline. Check whether your code version ships it before you set it up. The file names and variable names below are those of the starter files and can differ in your platform.

Prerequisites: where the reports go

The pipeline writes its reports to a storage account. Choose one of two options.

Option 1: the storage account of a spoke (preferred)

A fully deployed spoke has a storage account that fits. Make a spoke for the platform team, or use an existing one, and set a group of the people who need the reports as ProductTeamGroupNames in its spoke file (Spoke JSON reference). Then, after the spoke deployment:

  1. Create a container in the storage account, for example driftdetection.
  2. Give the Readers group of the spoke the role Storage Blob Data Reader on the storage account, so that they can read the files. If more people need access, create a group for them and give that group the role.
  3. Check the network access of the storage account. It is normally limited to its private endpoint. You may have to adjust it so that the readers can reach it, which in turn can need a policy exemption.

Option 2: another storage account

Use a regular storage account (not a data lake, no hierarchical namespace):

  1. Create a container, for example driftdetection.
  2. Make sure the deployment agents can reach the storage account, directly or, preferably, through a private endpoint.
  3. Give the service principal of the spoke deployment the role Storage Blob Data Contributor on it.

Create the pipeline

The pipeline file is part of the configuration repository of the spokes (starter name SpokeConfigurationDriftReporter.yaml in the pipelines folder).

  1. In the Azure DevOps project, create a new pipeline from an existing YAML file in the configuration repository, branch main, and the path of that file. Save it without running.
  2. Rename it, for example Spoke Configuration-drift Detection.

  3. Set the agent pool in the file to the pool you use:

    pool: <agent-pool>

  4. Create the variable library described below.

  5. Run the pipeline once by hand. Azure DevOps asks for permission to use the pool and the library. A scheduled run cannot ask for that, so it fails until the first manual run is approved.

Variable library

The pipeline reads the storage account and the container from a variable group. The starter pipeline expects the name xms-spoke-driftdetection.

Key Value
DriftDetectionStorageAccountName The exact name of the storage account. Lower case, no spaces at the start or the end.
DriftDetectionStorageContainerName The container. Suggested: driftdetection. Same rules.

Schedule

The schedule is in the pipeline file:

schedules:
  - cron: "<minutes> <hours> <days> <months> <days-of-week>"
Field Range
minutes 0 to 59
hours 0 to 23
days 1 to 31
months 1 to 12 (names are also accepted)
days of week 0 to 6, where 0 is Sunday (names are also accepted)

* means any value. Azure DevOps evaluates the time in UTC. Run it at least weekly, in line with the Maintenance calendar.

Get a report

Every run stores the report twice in the container:

Use Name
History: a unique name per run ConfigurationDriftReport_<yyyy-MM-dd HHmm>.json
Automation: always the newest report ConfigurationDriftReport_lastest.json (spelled like this in the source)

To read one, open the storage account in the Azure portal, then Storage browser, Blob containers, and the driftdetection container. You need the Storage Blob Data Reader role. Automation can read the latest file.

Act on a report

For every spoke in the report that shows changes:

  1. Find out who changed what (Azure activity log) and why.
  2. If the change is needed, bring it into code: a spoke change.
  3. If not, run the spoke deployment, which reverts it (Spoke deployment).
  4. Include the number of drifting spokes in the monthly health check.