Service connection

What it is

An Azure DevOps service connection is a named connection configuration that lets a pipeline authenticate to an external service, such as an Azure subscription or container registry. It links the target service with an authentication method and Azure DevOps permissions; it is not itself the Azure identity or the network path.

Why it exists

Pipeline YAML should describe work, not contain reusable cloud credentials. A service connection keeps the target and authentication configuration outside the YAML and can apply permissions and checks to its use. The underlying identity still needs least-privilege permission at the target Azure scope.

Not the same as

• service-endpoint — an Azure networking feature that keeps a PaaS service’s public endpoint but limits access from selected VNets. It does not authenticate a pipeline.
• private-endpoint — a private network interface for a PaaS service. It does not grant a pipeline permission.
• service-account — the underlying non-human identity. A service connection can use a service principal or workload identity federation, but it is the pipeline integration object, not the identity itself.
• subscription-connection — the previous vault name for the Azure subscription form of this concept. Use this page as the canonical cross-platform explanation.

Operational failure mode

A pipeline can be valid YAML yet fail at deployment because the service connection lacks RBAC at the target scope, is not authorized for that pipeline, or cannot obtain a token. Diagnose identity, target scope, connection authorization, and network reachability separately.

Northwind example

Northwind creates an Azure Resource Manager service connection named orders-prod. It uses workload identity federation, so the pipeline does not store an Azure client secret. The service principal receives only the deployment role required for the production order resource group, not Contributor on the whole subscription. A pipeline can reference orders-prod, but Azure DevOps checks whether the pipeline is authorized to use that connection; Azure RBAC separately decides whether its underlying identity can deploy the requested resource.

Choose the identity path

• Prefer workload identity federation for Azure Pipelines deployments that can use short-lived tokens.
• Use a managed identity when an Azure-hosted workload accesses Azure services directly.
• Use a stored secret only when the target cannot support a safer identity flow, then protect and rotate it deliberately.

Related

subscription-connection · service-principal · managed-identity · workload-identity-federation · pipeline-security

📘 Source: Microsoft Learn — Resource Manager workload identity service connection