What are Service Connections in Azure DevOps, and how do they securely connect to AWS, Azure, or Kubernetes?

Think of a Service Connection like a valet key for your car. You hand the parking attendant (pipeline) a key that can drive and park the car but cannot open the trunk or glove box. The valet never sees your master key, and you can revoke the valet key anytime without changing your locks.

Service Connections are configured at the project level under Project Settings and store credentials encrypted at rest. Each connection type has a specific authentication mechanism: Azure connections use Service Principals or Managed Identity with workload identity federation, AWS connections store access key ID and secret (or use assumed roles), Kubernetes connections use kubeconfig or service accounts, and Docker connections use registry credentials or service principals.

When a pipeline references a service connection, the Azure DevOps agent decrypts the credentials at runtime and injects them into the task execution context. The credentials never appear in logs (they are masked automatically) and are not accessible to other pipelines unless explicitly shared. Administrators control which pipelines can use a connection through security settings — you can require approval before a new pipeline uses a sensitive production connection.

In production environments, the best practice is workload identity federation for Azure connections, which eliminates stored secrets entirely by using OIDC token exchange. For AWS, teams use short-lived assumed roles via the AWS Toolkit task rather than long-lived access keys. For Kubernetes, connections should use namespace-scoped service accounts with RBAC rather than cluster-admin tokens.

The critical gotcha is the 'Grant access permission to all pipelines' checkbox that appears when creating a connection. Checking this allows any pipeline in the project to use the connection without approval, which is a security risk for production credentials. Senior engineers always uncheck this and configure pipeline-level permissions explicitly, especially for connections to production AWS accounts or Kubernetes clusters.