Introduction

Last year I posted on how to create your own Azure DevOps maintenance jobs. This solution has been working well for me, until the Azure DevOps Service connection’s Entra ID Service Principle secret expired.

So, I thought it well worth revisiting the creation of this maintenance job but this time using Workload Identity federation to authenticate, and hence never again have to worry about the secret expiring.

Updated Setup Process

Note: This is a modification to the creation of the service connection, but the core the maintenance job setup remains the same as in my original post

1. In the Azure DevOps select the Team Project that the maintenance job will run in, and create a new Service Connection of type Azure Resource Manager and the default type Workload Identity federation (automatic). Pick the Azure Subscription that the Azure DevOps instance is linked to.

2. Once the Service Connection is created, in the Azure Portal check the Entra ID directory for the newest App Registration (Service Principle) that you own. Unfortunately using this setup method, you have no control over the name of this App Registration, but you can probably assume it will be the newest one you own. It will be in the from [AzDo Org]-[Team Project]-[Subscription ID] format e.g. blackmarble-source-bm-3ed896d7-9999-9999-99999999999.

   Important: You could have multiple App Registrations with the same name, so you need to make a note of the Client ID in the Overview blade of the App Registration as you need it later

3. Back at the Azure DevOps organisation level you need to add the newly created Service Principle as a known user. This is where knowing the Client ID is important, as you can use it to identify the correct entry because the Client ID is shown as a subscript on each entry. I granted my new Service Principle Basic level access to be able to query the AZ CLI.

   

   Note: You might get away with Stakeholder access, but I knew my maintenance jobs needed source code access so I had to have Basic level

   Note:

   If you fail to perform this step you see the fairly unhelpful error

   ERROR: TF401444: Please sign-in at least once as {GUID Identifier} in a web browser to enable access to the service.

4. You can now ready to update your scheduled maintenance job trigger YAML to use the new Service Connection, and then attempt it. You will probably get permission errors, these will vary depending on what you are trying to do. In my case I am trying to queue builds so the permissions I need to grant the Service Principle in Azure DevOps are

   • At the Org level reader access to the Agent Pools
   • At the Team Project level reader access
   • At the Team Project level permissions to queue builds and edit build queue configuration

Summary

Moving to Workload Identity federation is a great way to avoid the issue of Service Connection secrets expiring. It is a little more complex to setup, but once done it is a great way to authenticate your maintenance jobs or any other Azure DevOps to Azure interactions.

For the original version of this post see Richard Fennell's personal blog at How to run your own maintenance job on Azure DevOps pipelines (Revisited now using Workload Identity federation)