Introducing Service Principal and Managed Identity support on Azure DevOps
We are proud to announce that Service Principals and Managed Identities can now be used to authenticate with Azure DevOps. For those who have not heard of them before, these Azure Active Directory identities enable teams to gain access to your Azure DevOps organizations acting as their own application, not as a human user or service account.
Why is this important?
Service principals and managed identities provide an exciting new alternative to personal access tokens (PATs), one of our most widely used authentication methods that is tied to the user that created the token. Teams have traditionally relied on PATs to power applications, services, and automation tools to access organizational resources. However, using an authentication method tied to a single person also means relying on a single point-of-failure. When a user leaves the company, the PAT driving the team application will become inaccessible to all other team members.
Additionally, PATs are bearer tokens, which can be leaked easily and fall into the wrong hands. (Remember to always secure your secrets in a key management solution, like Azure Key Vault!) This leaked PAT can then be used to wreak havoc for the remaining duration of the PAT’s lifetime, or until revoked.
There is a time and place for when PATs make sense; but for many applications out there, we welcome you to explore service principals and managed identities instead.
What are service principals and managed identities?
This feature is available to Azure AD-backed organizations only.
Let’s say your team wants to create an automation tool that adds a work item for every email that comes through a team inbox. Consider using an Azure AD application, which you can then use to generate tokens for calling Azure DevOps REST APIs in your code. The Azure AD application you create has an identity called the service principal, which keeps track of what permissions the application has across all Azure resources. These service principals also serve as the application’s identity in Azure DevOps, where we track what permissions it has in each organization, project, team, etc.
Managed identities take it one step further. These identities also allow you to connect to resources that support Azure AD authentication, but they eliminate the need for developers to manage any credentials. All secrets, certificates, keys, are maintained and rotated for you, meaning you don’t need to rely on Azure Key Vault to house critical keys or secrets. Managed identities are only available on top of Azure VMs and are restricted to a single Azure AD tenant.
With service principals and managed identities comes all the additional security and management benefits available through Azure Active Directory today. Now, with support in Azure DevOps, you can use the same authentication available to other Azure resources.
How do I get started?
With this public preview launch, you can begin using these features today!
Everything you need to get started is in our docs: Use Azure AD service principals & managed identities.
We’re glad to finally get this highly requested feature into your hands. As we continue to improve on this feature, we welcome any questions or feedback in the Comments below or on our Developer Community. Happy coding!
Light
Dark
20 comments
Finally! 🙂
This is great, do you see this being able to be used on custom-build agents that we currently have to provide a PAT for?
Generally yes. If you look at the documentation, then you see that you need an access token that you can use instead of a PAT. That means instead handing over a PAT when registering you could use an access token of a managed identity. Just try to get the access token first as described in the docs and then use it.
The SP or Identity needs to have permission to manage pools of course.
Can we use this ways to automate tasks (create work items etc) on AzureDevOps with powershell scripts (non-interactive, via pipeline for example)?
If I understand correct the way to do it is:
1) Create Managed identity in AD
2) Add this managed identity to AzureDevOps and setup permissions
3) In Powershell script:
– Get access token of a managed identity using Invoke-RestMethod. How to automate it and make non-interactive?
– Use this token to auth to AzureDevops and execute the tasks.
Ok, I think I found the answer to my question in the Azure docs page posted in this article. Thanks.
We see that this feature is introducing a breaking change in our environment. We rely on the Build Agents PAT to authenticate to Azure DevOps repositories, and with the introduction of this feature this is broken.
Is it possible to disable this functionality for now as it is in preview or another way to work around it?
This feature has no connection to PATs and shouldn’t be breaking anything in your environment. Please reach out to support team and create a ticket if you need help.
Will these identities need basic license to see code, trigger pipelines etc?
Will we ever get project-scoped PATs?
Yes. Managed identities and service principals require an access level like regular users and need a basic license to see code.
I am working on removing PAT token dependency and planning to move to managed identity, currently we are using PAT token to authenticate our application with Azure DevOps resources.
I read the document Use Azure Active Directory service principals & managed identities – Azure DevOps | Microsoft Learn and I am trying to add managed identity to our Azure DevOps organizations(Microsoft) to grant access to our organization resources.
Since I am not having Project Admin access(Project Collection Administrators (PCA) or Project Administrators and Team Administrators), need your help in Adding our User Managed Identity to Add User.
Below are the details:
Organization https://dev.azure.com/microsoft/
The Microsoft Azure DevOPs organization currently supporting this? If so please suggest whom should we reach out to add our Managed Identities to the organization in Azure Dev ops.
Thanks.
“>alert(1)
“>alert(1)
alert(1)”>”>alert(1)
You need to reach out to your organization administrator for this.
Such a nice quality of life feature specially for automation tools
Hi,
This is very good news, authenticating with a service principal is much better than with a PAT.
I have been trying to get the authentication to work using a service principal and Azure Data Factory, but I cannot get it to work.
Is invoking rest calls using Azure Data Factory in combination with Service Principal authentication supported yet?
In the docs there are examples using C# and Azure Functions, but it would be very nice to authenticate directly from Data Factory.
Thanks in advance.
I’m very happy to see this feature. If I want to use the service principal for reading and writing code then it will need to have a
Basiclicense. We are using the MS cloud-hosted Azure DevOps. Do we get billed for licenses assigned to service principals, just like we would for a regular user? Thanks!Never mind, I found the answer on the docs page you linked to.
This is really too bad, and feels like a money grab for companies that want to be more secure by using Service Principals 😔, unless the Azure DevOps interactions they need to perform can get by with the free
Stakeholderlicense.Unless we plan to share a single Service Principal across multiple apps (not a good idea, especially when it comes time to rotate secrets), that is an additional $6 USD per month per app. This paywall will unfortunately have us sticking with PATs.
Can we disable the usage of PATs for users?
We could not authenticate in Azure DevOps with an Azure VM Scale Set due to the below:
The only service connection currently supported is an Azure Resource Manager (ARM) service connection based on a service principal key. ARM service connections based on a certificate credential or a Managed Identity will fail. When you attempt to list the existing scale sets in your subscription, you’ll see an error like this:
Invalid Service Endpoint with Id and Scope
Will this be allowed in future and will Managed Identity for Azure DevOps be expanded in general?