Hello!

I got caught out by something this week: looks like updating a password in an Azure DevOps service connection is not quite as straightforward as I had expected. As a project administrator I went to update the secret of a service connection as the service principals key was close to expiring. I entered the new value, hit ‘verify’, and once that was confirmed I went to hit save. However, I got a strange error message:

“You need to be an organisation/collection level Administrator of the service endpoint to perform this operation”

Oh! This confused me somewhat, as after I had red the message I thought I had to be in an organisation level administrator group. But no, come to find out that I need to edit the permissions on the endpoint I am changing in order to be able to update the value of the secret. This is because there are two levels of permissions on the endpoint; project and organisation. The reason for doing this is that a service connection can be shared across projects. And so the organisation-level administrator will have the ability to edit all the fields of a service connection, whilst the project-level admins can rename, update the description and enable/disable pipeline sharing. I would’ve assumed that changing the name would break a whole organisation accessing the service connection and the separation seems a little arbitrary.

Anyway, when the service connection is created the creator is added to the admins list, and when this feature was introduced the Endpoint Administrators were also added to connections that already existed, for “backwards compatibility”. This splitting of permissions seems rather myopic as it does not take into account that there is nothing that makes these permissions nuances glaringly obvious until you find yourself in the situation where the original creator has moved on and the service connection cannot be altered without having to get an organisation admin to go in and add a group to have the organisation-level administrators permissions.

An alternative would be to rename this service connection and then re-create it without having to get more people involved. This again highlights the banality of splitting the permissions.

In a moment of self-reflection I would expect most of you are thinking that this demonstrates the evilness of doing stuff manually by doing clicky-clicky in the Azure DevOps portal as opposed to automating the creation and management of service connections, and you’d be right. And whilst I would spend more time figuring out how to automate this than I ever would manually updating the keys, it is not time that is being saved here but hassle. Making sure that a group is given administrator access to the organisation-level permissions can only be guaranteed through automation as well. I’m going to file this under “technical debt”.