Introduction
Azure DevOps, by default, lacks a direct link to services or platforms to authenticate and authorize without proper configuration. To establish a secure connection to both internal and external services, Azure DevOps requires the creation of Service Connections. These connections can be utilized to access a variety of services such as Azure resources, GitHub repositories, Docker registries, npm feeds, and more.
Service Connections offer a secure method for storing and managing credentials and connection information. They can accommodate various authentication methods, from username and password to service principals and access tokens, to regulate the access to service connections.
For the use case to deploy workloads to Azure, the “Azure Resource Manager” service connection type is required. Each authentication method has its pros and cons. The service principal is the most frequently used, most secure, and until now the “only” option for authenticating and authorizing a service connection on “external” tenants. Utilizing service principals to authenticate an Azure Pipeline has several benefits.
What are the benefits of service principals?
Service principals facilitate secure service-to-service authentication without human intervention, using either a certificate or a secret, which are more secure authentication methods than a username and password. With Azure Role Based Access Control (RBAC), the service principal can be assigned the exact permissions it needs to carry out its tasks, adhering to the principle of least privilege, a crucial aspect of Azure security practice. Service principals are independent entities that can be managed separately from user accounts, meaning they are not reliant on a specific user’s login information and are unaffected when a user leaves the organization or changes roles. Activities conducted using a service principal can be easily tracked and monitored, aiding in auditing and compliance adherence.
The “biggest sticking point”, or the main issue with service principals , is the monitoring and rotation of the client secrets or certificates. There’s also a risk of these secrets being stolen and misused for malicious intent. In theory, a client secret with the rights to “delete resources” could inflict significant damage on a subscription.
Workload identity federation
The recently introduced “workload identity federation” authentication method offers a solution to this problem. Authentication is carried out via OpenID Connect (OIDC), a widely used identity protocol based on OAuth 2.0. This offers a contemporary solution to the issue of monitoring and rotating service principal secrets, enhancing the security of applications and services. After the authentication method went general available in February, you now have the possibility to authenticate your Service Connections to external tenants. This means, that you don’t need the client secrets anymore, if you’re deploying workloads to other tenants than yours.
Setup the service connection with workload identity federation
To set up the service connection navigate to your DevOps organization, your desired project and go to the “project settings”. Under the project settings you can add service connections (Pipeline settings). Now if you create a service connection with workload identity federation you have to choose the “Azure Resource Manager” type and create a “manual Workload Identity federation” connection. If you create an “automatic” one, you only will see resources residing in the tenant of the DevOps organization.
- Create a name and a description. It is wise to name them properly and clear 馃槈
- Afterwards you will see an “Issuer” and a “subject identifier”. Those values you need for the service principal with workload identity federation.
- The workload identity federation authentication still resides from a service principal. Thus, you have to create a service principal via Azure Portal or via PowerShell.
- After you have created the service principal you can delete the recently created client secret. The client secret will be created automatically only if you create the service principal via PowerShell.
- Afterwards navigate to the tab “Federated credentials” and add a credential.
- Chose “Other issuer” and add the previously copied “Issuer” and “subject identifier”. In the end give the credentials a name.
- Now you can give the service principal permissions on which level you want (Management group, Subscription, or resource group).
- Finish the service connection setup in the Azure DevOps with the values needed.
- Now you can deploy your workloads to “external” tenants in a secure manner.
If you are already using service principals with client secrets for DevOps Pipeline authentication, Microsoft gives you the opportunity to migrate them to workload identity federation. More information here:聽Connect to Azure by using an Azure Resource Manager service connection
Sources:
Manage service connections
Connect to Azure by using an Azure Resource Manager service connection