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 access to service connections.
Benefits and Pitfalls 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 (short 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 for securing your Azure environment. 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 like normal user identities.
The “biggest sticking point,” or the main issue with service principals, is the monitoring and rotation of client secrets or certificates. There’s also a risk of these secrets being stolen and misused for malicious intent. A client secret with the rights to “delete resources” could inflict significant damage on a subscription if compromised.
Workload Identity Federation: A Modern Solution
The workload identity federation-authentication method, which was introduced in early 2024, addresses this issue. Authentication is executed via OpenID Connect (short OIDC), a widely used identity protocol based on OAuth 2.0. This modern solution solves the trouble of monitoring and rotating service principal secrets while enhancing the security of applications and services. As of February 2024, you now have the possibility to authenticate your Service Connections to external tenants without needing client secrets.
Setup The Service Connection With Workload Identity Federation
To set up the service connection, navigate to your DevOps organization, select your desired project, and go to the “project settings.” Under the project settings, you can add service connections (Pipeline settings). When creating a service connection with workload identity federation, choose the “Azure Resource Manager” type and opt for a “manual Workload Identity Federation” connection. If you select “automatic,” you will only see resources residing in the tenant of the DevOps organization and won’t have the opportunity to create the app registration according to your naming standards.
Step 1: Sign in to your Azure DevOps organization
- Open your web browser:
- Launch your preferred web browser (e.g., Chrome, Firefox, Edge, etc.).
- Navigate to the Azure DevOps portal:
- Enter the following URL into your browser’s address bar: https://aex.dev.azure.com/.
- Sign in with your credentials:
- Click on the “Sign in” button if you’re not already logged in.
- Enter your Azure DevOps account email address and password.
- If you have multi-factor authentication enabled, complete the additional verification steps as required.
Step 2: Navigate to your project settings
- Select your organization:
- Once logged in, you will see a list (or only one or none) of organizations you are a member of. Select the organization where your project resides.
- Select your project:
- After selecting the organization, you will see a list of projects. Click on the project you want to configure the service connection for.
- Open Project Settings:
- Look for the gear icon in the lower-left corner of the project overview page and click on it.
- This will take you to the settings menu specifically for that project.
Step 3: Create a service connection
- Go to Service Connections:
- In the “Project Settings” menu, under the “Pipelines” section, select “Service connections.”
- Add a new service connection:
- Click on the “New service connection” or the “+” button to create a new service connection.
- Choose connection type:
- From the list of available connection types, choose “Azure Resource Manager.”
- For this guide, opt for the “manual Workload Identity Federation” option.
Step 4: Provide a clear and descriptive name and description
- Enter a service connection name:
- Provide a clear and descriptive name for your service connection. The name should clearly indicate its purpose.
- Enter a description:
- Add a detailed description that provides context or explains the use case of this service connection.
Step 5: Configure Identity Federation settings
- Issuer and Subject Identifier:
- After creating the service connection, you will be presented with an “Issuer” and a “subject identifier.” Copy these values as they will be used in the next step.
Step 6: Create a service principal via the Azure Portal or PowerShell
- Create a service principal in the Azure Portal
- Create a service principal using PowerShell
Step 7: Configure service principal for Workload Identity Federation
- Remove client secret (if created automatically via PowerShell):
- If client secrets were created, remove them from the Azure Portal under the service principal’s “Certificates & secrets” section.
- Add federated credential:
- Go to the “Federated credentials” tab for the service principal.
- Click on “Add a credential” and choose “Other issuer.”
- Enter the “Issuer” and “subject identifier” you copied earlier.
- Provide a meaningful name for this credential.
Step 8: Grant appropriate permissions
- Assign roles/permissions:
- Assign the appropriate roles to the service principal for the resources it needs to access.
- This can be done at the Management group, Subscription, or Resource group level depending on your requirements.
- Navigate to the relevant resource in the Azure Portal, go to “Access control (IAM)”, add a role assignment, and select your service principal.
Step 9: Complete service connection setup in Azure DevOps
- Finalize setup:
- Return to the Azure DevOps portal where you created the service connection.
- Complete the setup by entering any remaining required values such as subscription ID, Tenant ID, and confirm the connection.
Migrating Existing Service Principals
If you are already using service principals with client secrets for DevOps Pipeline authentication, Microsoft offers the possibility to migrate them to workload identity federation. For more information, see Connect to Azure by using an Azure Resource Manager service connection.
In my experience, attempting to migrate these existing connections did not work seamlessly. Therefore, the simplest and most efficient approach is to create a new service connection from scratch.
Conclusion
Microsoft’s decision to enable workload identity federation for Azure DevOps Service Connections represents a significant step forward in enhancing security. By using OIDC for authentication, it reduces the vulnerabilities posed by client secrets and certificates while ensuring the safe deployment of workloads to external tenants. By carefully managing service connection settings, you can balance security and functionality, improving the efficiency and protection of your Azure DevOps environment.
For detailed guidance on service connections, refer to Manage service connections.